Re: Can develop across forest, just can't install (was: Need to be a schema admin just to install???)

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

FYI, I later found out that while you can develop and deploy across all
domains in the same forest as the Exchange instance you are managing, in
fact most cmdlets do not work across forests (move-mailbox being one notable
exception to that rule). I was told by an MS Exchange engineer that they
plan to make 2010 management tools fully remotable though. Oh well, guess
I'll have to rethink my deployment a bit for now.

"Michael Dragone" <newsgroup@xxxxxxxxxxxxxx> wrote in message
news:eZBj%23vkKJHA.3808@xxxxxxxxxxxxxxxxxxxxxxx
Hmm. Like you said, not the cleanest solution but handy to have around.
I'll have to keep that one in the book for later.

"Steve Schuler" <sjschu@xxxxxxxxxx> wrote in message
news:#PU0OrkKJHA.4988@xxxxxxxxxxxxxxxxxxxxxxx
So I got an answer on this through our MS support representatives helping
us with a con call with an engineer. (Great support, BTW, MS, thank you!)
The bottom line is the install checks the presense of the schema against
the workstations local domain during configuration. But you can move /
join the workstation to a domain that doesn't have the schema extensions
later and configure the tooling to manage a foreign domain / Exchange as
long as there's a trust and the foreign domain has the extensions. Not
the cleanest install perhaps, but this should be workable (note to MS:
how about an option to specify a domain where Exchange lives during
install?)

"Michael Dragone" <newsgroup@xxxxxxxxxxxxxx> wrote in message
news:OmIsXgkKJHA.5232@xxxxxxxxxxxxxxxxxxxxxxx
As far as I know, this is the case - you have to have Exchange 2007
present first before installing the management tools.

"Steve Schuler" <sjschu@xxxxxxxxxx> wrote in message
news:#NBDd1iKJHA.2164@xxxxxxxxxxxxxxxxxxxxxxx
The Exchange deployment is for externally facing customers in an
external forest in the DMZ, while the developers are in an internal
forest that is trusted by the domains in the external forest. The
internal forest is using Exchange 2003 currently. It seems that at
minimum you have to have Exchange 2007 in the forest where you install
the management tools. I suppose a workaround is to move the developer's
boxes and join them to the external forest, but this is not something
we like to do. I'm now pursuing the approach of yesteryear though: set
AD properties directly, as ADSI / DirectoryEntry doesn't have any
"artificial" requirement imposed on development environment (e.g., it's
possible to write ADSI / DirectoryEntry code on a standalone
workstation).

"Michael Dragone" <newsgroup@xxxxxxxxxxxxxx> wrote in message
news:OqQcCTiKJHA.5232@xxxxxxxxxxxxxxxxxxxxxxx
This doesn't seem right to me - I recall installing the 32-bit version
of the management tools on a Windows Server 2003 box with an account
that wasn't in either Enterprise Admins or Schema Admins.

How have you deployed your actual Exchange 2007 server(s)?

"Steve Schuler" <sjschu@xxxxxxxxxx> wrote in message
news:eQeuH$ZKJHA.4940@xxxxxxxxxxxxxxxxxxxxxxx
Hello all - I'm just getting into this, and hopefully this is just a
newbie question.

We are going to do some custom Exchange 2007 provisioning and our
intent is to wrap calls to the management tools PSCmdlets in our own
C# class. So my first thought is I need to get the Exchange
Management Tools installed. This is 32 bit development on a XP SP2. I
tried the instructions here
http://support.microsoft.com/default.aspx/kb/555841, but when we get
to the Readiness Checks we get the following

Summary: 2 item(s). 1 succeeded, 1 failed.

Elapsed time: 00:01:53





Management Tools Prerequisites

Completed



Elapsed Time: 00:00:08





Organization Prerequisites

Failed



Error:

The Active Directory Schema must be modified and this user account
has insufficient permissions. It must be a member of both the 'Schema
Admins' and 'Enterprise Admins' groups.

Recommended Action:
http://go.microsoft.com/fwlink/?linkid=30939&l=en&v=ExBPA.3&id=2fafe5d4-04e0-4c5a-a69f-7613d438131f



Error:

Global updates need to be made to Active Directory, and this user
account is not a member of the 'Enterprise Admins' group.

Recommended Action:
http://go.microsoft.com/fwlink/?linkid=30939&l=en&v=ExBPA.3&id=fb97f691-d7c3-40b6-8515-95fd489db46e



Error:

The local domain needs to be updated. You must be a member of the
'Domain Admins' and 'Exchange Organization Administrators' group, or
'Enterprise Admins' group to continue.

Recommended Action:
http://go.microsoft.com/fwlink/?linkid=30939&l=en&v=ExBPA.3&id=57887854-be52-43eb-9549-e854e4dbe33b



Error:

Setup needs to contact the Active Directory schema master but this
computer is not in the same Active Directory domain as the schema
master (DC=XXX,DC=XXXXXXX,DC=com).

Recommended Action:
http://go.microsoft.com/fwlink/?linkid=30939&l=en&v=ExBPA.3&id=2376fec1-b9ce-44db-beb6-cb9ac4788988



Error:

Setup encountered a problem while validating the state of Active
Directory: Exchange organization-level objects have not been created,
and setup cannot create them because the local computer is not in the
same domain and site as the schema master. Run setup with the
/prepareAD parameter on a computer in the domain XXX and site
Puget-Sound, and wait for replication to complete.



Warning:

The Active Directory schema will be upgraded if you continue. Verify
that the organization is ready for Exchange 2007 by running the
Exchange 2007 Readiness Check, which is part of the Exchange Best
Practices Analyzer.





Elapsed Time: 00:00:06



These purported requirements are untenable. What is the recommended
approach for developing custom code against the maangement PSCmdlets,
and what are the development environment requirements?



Thanks, Steve Schuler








.

Relevant Pages

  • Re: Can develop across forest, just cant install (was: Need to be a schema admin just to install???)
    ... But you can move / join the workstation to a domain that doesn't have the schema extensions later and configure the tooling to manage a foreign domain / Exchange as long as there's a trust and the foreign domain has the extensions. ... It must be a member of both the 'Schema Admins' and 'Enterprise Admins' groups. ... Global updates need to be made to Active Directory, and this user account is not a member of the 'Enterprise Admins' group. ...
    (microsoft.public.exchange.development)
  • Can develop across forest, just cant install (was: Need to be a schema admin just to install???)
    ... bottom line is the install checks the presense of the schema against the ... configure the tooling to manage a foreign domain / Exchange as long as ... The Active Directory Schema must be modified and this user account has ... Admins' and 'Enterprise Admins' groups. ...
    (microsoft.public.exchange.development)
  • Re: E2K3 / Changes to AD Schema
    ... There are many changes that get made as you extend the schema; Exchange 200x ... is highly dependent on Active Directory. ... If you have extended the schema before, you may run into a conflict. ...
    (microsoft.public.exchange.design)
  • Re: Chnages to Company Structure - Need to Create New Domains/Subdomains could do with pointing
    ... I am not an Exchange expert but the Exchange store could manage multiple ... one Exchange forest per Active Directory forest. ... To clarify the companies in question will be entirely separate ... Is this doable by keeping one Active Directory Structure and being ...
    (microsoft.public.windows.server.active_directory)
  • Re: gracefully removing a child domain
    ... forest and using ADMT to transfer their accounts prior to cut over? ... Then with Exchange, you have to figure out what to do with the mailboxes. ... would be beneficial, of small, a migration would be easier to clean out the ... PPT Presentation - Active Directory Design and Deployment- Tales of the ...
    (microsoft.public.windows.server.active_directory)