Follow us on Twitter
Follow us on YouTube
Would you like to suggest a topic for the Exchange team to blog about? Send suggestions to us.
It is possible while installing the Active Directory Connector (ADC), or while running an Exchange setup Forestprep action, to be greeted with this incredibly generic error message:
Extending the schema in the Active Directory failed. Please consult the error log LDIF.ERR in your TEMP directory.
When presented with this error message, you might dutifully go off to find yourr LDIF.ERR log, as directed, and find nothing of the sort present in your temp directory. So now what?
Well, one possible explanation is that you’ve got spaces in your temp dir path. I know, I know – what up? Here’s the scoop: Exchange setup and ADC setup both need to import a bunch of schema into Active Directory 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 user’s 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, we’ll 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, it barfs so early that it isn’t even able to write an LDIF.ERR log to the TEMP dir.
Why does ldifde.exe panic when it gets our string? That’s where the bug is — I’m guessing ldifde.exe reads the trailing backslash and quotation mark at the end of the string (\”)as an escape sequence, and so doesn’t think the string is actually formatted correctly. The owners of ldifde are currently investigating this.
How is it that you’ve 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\Temp …no spaces there, which is why most users don’t experience this problem. A user would have to manually change their temp dir path to get spaces in it… or 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-oh… Forestprep 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. We'll have a KB article about this created in the next few weeks.