I am trying to install Exchange 2007 and I get the following error when setup is trying to install the Hub Transport: Entering ScInstallLDIFScript[2/7/2007 9:25:31 AM] [2] ScRunLDIFScript (f:\08.00.0685\sources\dev\admin\src\libs\exsetup\exmisc.cxx:888) Error code 0XC1037AE6 (31462): Extending the schema in the Active Directory failed. Please consult the error log LDIF.ERR in your TEMP directory.[2/7/2007 9:25:31 AM] [2] ScInstallLDIFScript (f:\08.00.0685\sources\dev\admin\src\libs\exsetup\server.cxx:149) Error code 0XC1037AE6 (31462): Extending the schema in the Active Directory failed. Please consult the error log LDIF.ERR in your TEMP directory.[2/7/2007 9:25:31 AM] [2] Leaving ScInstallLDIFScript[2/7/2007 9:25:31 AM] [2] CAtomOrgLevelCt::ScAddDSObjects (f:\08.00.0685\sources\dev\admin\src\udog\exsetdata\components\server\a_orglevelct.cxx:379) Error code 0XC1037AE6 (31462): Extending the schema in the Active Directory failed. Please consult the error log LDIF.ERR in your TEMP directory.[2/7/2007 9:25:31 AM] [2] Leaving CAtomOrgLevelCt::ScAddDSObjects[2/7/2007 9:25:31 AM] [2] CBaseAtom::ScRefreshDSObjects (f:\08.00.0685\sources\dev\admin\src\udog\setupbase\basecomp\baseatom.cxx:1476) Error code 0XC1037AE6 (31462): Extending the schema in the Active Directory failed. Please consult the error log LDIF.ERR in your TEMP directory.[2/7/2007 9:25:31 AM] [2] CAtomOrgLevelCt::ScReinstall (f:\08.00.0685\sources\dev\admin\src\udog\exsetdata\components\server\a_orglevelct.cxx:169) Error code 0XC1037AE6 (31462): Extending the schema in the Active Directory failed. Please consult the error log LDIF.ERR in your TEMP directory.[2/7/2007 9:25:31 AM] [2] Leaving CAtomOrgLevelCt::ScReinstall[2/7/2007 9:25:31 AM] [2] mode = 'Reinstall' (61955) CBaseAtom::ScSetup (f:\08.00.0685\sources\dev\admin\src\udog\setupbase\basecomp\baseatom.cxx:535) Error code 0XC1037AE6 (31462): Extending the schema in the Active Directory failed. Please consult the error log LDIF.ERR in your TEMP directory.[2/7/2007 9:25:31 AM] [2] ScSetupAtom (f:\08.00.0685\sources\dev\admin\src\udog\exsetdata\exsetds.cxx:889) Error code 0XC1037AE6 (31462): Extending the schema in the Active Directory failed. Please consult the error log LDIF.ERR in your TEMP directory.[2/7/2007 9:25:31 AM] [2] Leaving ScSetupAtom [ERROR] An error occurred. error code was 3238230758 message was Extending the schema in the Active Directory failed. Please consult the error log LDIF.ERR in your TEMP directory.."[2/7/2007 9:25:31 AM] [1] The following 1 error(s) occurred during task execution:[2/7/2007 9:25:31 AM] [1] 0. ErrorRecord: An error occurred. error code was 3238230758 message was Extending the schema in the Active Directory failed. Please consult the error log LDIF.ERR in your TEMP directory.."[2/7/2007 9:25:31 AM] [1] 0. ErrorRecord: Microsoft.Exchange.Management.Deployment.ExsetdataException: An error occurred. error code was 3238230758 message was Extending the schema in the Active Directory failed. Please consult the error log LDIF.ERR in your TEMP directory.."[2/7/2007 9:25:31 AM] [1] [ERROR] An error occurred. error code was 3238230758 message was Extending the schema in the Active Directory failed. Please consult the error log LDIF.ERR in your TEMP directory.."[2/7/2007 9:25:31 AM] [1] Setup is halting task execution because of one or more errors in a critical task.[2/7/2007 9:25:31 AM] [1] Finished executing component tasks.[2/7/2007 9:25:31 AM] [1] Ending processing. I assume that the issue is with permissions in the AD Global Catalog but I am not sure.

Is the account you are using to install a member of the schema admin as well as exchange admin?

Yes I am using an account with both Enterprise Admin and Schema Admin rights. I am using a run as on the setup.exe from the cd.

can you post the error message that it references, sounds like its def. a persmission issue or a server role issue

one possible explanation is that youve got spaces in your temp dir path. Exchange setup and ADC setup both need to import a bunch of schema into the AD on initial installation. To do this, they call on a little Windows utility called ldifde.exe. Ldifde.exe takes as one of its parameters a directory path for the location of its log file. Our setups pass as this parameter the path to the current users TEMP directory. The code calls a Win32 API (GetTempDir()), which returns the value of the TMP/TEMP variables, and appends a trailing backslash to the string (presumably so a filename can be just tacked on the end). If our code gets back the temp dir string and finds a space anywhere in it, well enclose the whole string in quotation marks (perfectly reasonable string handling practice). However, when we pass a quoted string to ldifde.exe, it barfs. In fact, in barfs so early that it isnt even able to write an LDIF.ERR log to the TEMP dir. Why does ldifde.exe panic when it gets our string? Thats where the bug is Im guessing ldifde.exe reads the trailing backslash and quotation mark at the end of the string (\)as an escape sequence, and so doesnt think the string is actually formatted correctly. The owners of ldifde are currently investigating this. How is it that youve got a space in your temp dir path? Well, by default the temp dir path is something like D:\Documents and Settings\Alex\Local Settings\Temp. But wait, you say, there are spaces all over the place in that path. Right you are. However, by happy accident your temp dir variable actually gets constructed by default using 8.3 short file names. So the path becomes D:\DOCUME~1\Alex\LOCALS~1\Tempno spaces there, which is why most users dont experience this problem. A user would have to manually change their temp dir path to get spaces in itor would they? Another (this time not-so-happy) accident: you can disable 8.3 file name creation. There is, in fact, a registry key that will allow you to do this (intuitively named NtfsDisable8dot3NameCreation, found in HKLM\System\CurrentControlSet\Control\FileSystem). Set this value to 1, and 8.3 filename creation will be disabled. If a user logs on to a box where this setting is in effect, the userprofile for that user will include TMP/TEMP variables that look like this: D:\DOCUME~1\Alex\Local Settings\Temp. Uh-ohforestprep and ADC install fail. This registry setting is actually specified in many of the security templates found up on TechNet. The workaround is to remove the spaces in your temp dir path variables (SET TEMP=D:\SOMETHING\WITHOUT\SPACES; SET TMP=D:\SOMETHING\WITHOUT\SPACES), then run forestprep or ADC install, then set your variables back the way you had them http://support.microsoft.com/default.aspx/kb/917682 is a KB article on it

Thanks for the verbose help. I have figured out that the ldif.err is indeed in my Temp folder. I didn't find it before simply because I was looking in the wrong spot. I didn't realize that the install would use my account temp versus the windows temp. I even did a search, using the built in search tool, and didn't return any file named ldif.*. This however, brings me to the real problem which is the following error: Connecting to "DomainController" The connection cannot be established The error code is 8224 I do not have a problem getting to any files or folders on the DC from the server and am able to authenticate users from the server. In fact, I added the server to the domain just before started the Exchange install process. Do you have some insite into this error code?

It all depends on what you are trying to do. Let's just say that you have the following OU structure:DC=Domain,DC=Com OU=Offices OU=San Diego OU=Los Angeles OU=San Francisco OU=OaklandLet's say that there is a security group that resides in OU=Offices ( called "Company" ) and that there is a security group in each of the sub-OUs ( in the OU=San Diego the security group is called 'San Diego", in the OU=Los Angeles the security group is called "Los Angeles", etc. ).So, if you want to get the membership of each of the five groups you would enter something like this:c:\>ldifde -f c:\groups.ldf -s dc01.domain.com -t 389 -d "OU=Offices,DC=Domain,DC=Com" -p subtree -r "(objectClass=group)" -l "cn,groupType,member"This will bind to the DC named dc01.domain.com using the default port of 389. It will start its search at 'OU=Offices,DC=Domain,DC=Com' and look only for objects that meet the requirements of the seach filter ( objectClass=group ). For each object that it finds it will return the value of the three attributes that you have specified ( -l ).So, it would find the group Company, San Diego, Los Angeles, San Francisco and Oakland. For each of these five groups it would return the values for the CN, groupType and member attributesIs this clear?Now, let's say that you want to do this for a specific group. Let's just pick the Oakland group. You would enter something like this:c:\>ldifde -f c:\oakland.ldf -s dc01.domain.com -t 389 -d "CN=Oakland,OU=Oakland,OU=Offices,DC=Domain,DC=Com" -l "cn,groupType,member"This is a little bit different. Since we are binding to the group directly we do not really need to use any search filter ( the -r switch ). All we really need to do is to specify the attributes for which you would like the values!can you post the exact error message from event log?

Thanks to your help, I discovered that the problem was with the domain name and the dns settings in the tcp/ip properties. My AD domain name is "foo.local". So in the dns properties, I set the dns suffix for this connection to foo.local, and the "append these dns suffixes" to foo.local. After trying your command line example above, I discovered that the connection was not being made due to insufficient privileges. I modified the line to: c:\>ldifde -f c:\oakland.ldf -sfoo.local -t 389 -d "CN=Oakland,OU=Oakland,OU=Offices,DC=foo" -l "cn,groupType,member" Lo and behold, a successful connection. I made the changes to the tcp/ip settings and the installation continued as intended. Thanks for your timely responses!