Creating user and mailbox in Exchange System Manager (2007 Beta 2). Fails. Summary: 1 items. 0 succeeded, 1 failed. Elapsed time: 00:00:00 dpe122Failed Error:Organizational unit "ROOT/Users" was not found. Please make sure you have typed it correctly. Management Shell command attempted:New-Mailbox -Name:'dpe122' -Alias:'dpe122' -OrganizationalUnit:'ROOT/Users' -Database:'CN=Mailbox Database,CN=First Storage Group,CN=InformationStore,CN=DARIUS-WIN64,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=ORGROOT,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=ROOT' -UserPrincipalName:'dpe122@ROOT' -SamAccountName:'dpe122' -FirstName:'dpe122' -Initials:'' -LastName:'' -Password:'System.Security.SecureString' -ResetPasswordOnNextLogon:$false Elapsed Time: 00:00:00

Hi Brian, can you try using just 'Users' as the OU and see if that fixes it? Thanks, ~vivek

Vivek, thanks for your suggestions. We did some more investigation, thanks to your hints. We were able to use the command line in the monad shell to do the command that failed, and once we found out how to create and store the password, we did the command line and it said that 'users' was not a unique organizational unit. Then we tried another OU name that was unique in the tree, and it worked. So we can create the mailbox, but not through Exchange System Manager. Also, since the fully qualified OU didn't work, we are required to specify the name of a unique OU and it appears the monad command is just looking for that OU anywhere in the tree. Hmmmm..... The Clinkinator.

How did you specify the full OU name? Did you try something like this: domain.subdomain.company.com\Users That is the full format for OU, so theoretically you can get really unique: domain.subdomain.company.com\Users\Users\Users Thanks, ~vivek

Our domain is called ROOT, so the fully qualified OU that the ESMwas trying to do was ROOT\Users.

I can reproduce this issue. It looks like this is a genuine bug and I will follow up on it. However, I should mention that having an active directory domain with just one identifier is not recommended by the active directory team. There is even a warning provided when you create a domain with just one identifier and extra active directory configuration will be required. It is recommended that you have multiple identifiers in your domain name, for example all of the below have multiple identifiers: company.com department.company.org company.local I will file a bug for this and follow up, but given that this scenario is uncommon and not recommended by the active directory team, I cannot guarantee that it will get fixed. -jim

Jim, thanks for the help. Odd thing is, it must have been broken in Beta 2 (or recently), because we did create mailboxes in earlier builds. Brian.

Also, do you think that our single label domain may have also caused Unified Messaging role not to install? I posted to the 'Deploy' newsgroup about this error: "Unified Messaging Role failed with error: This installation is forbidden by system policy." So far I haven't gotten any resolution for this, but maybe because of the single label domain it is having a problem reading group policy? The Clinkinator

I don't think the single lable domain is causing the Unified Messaging issue you are seeing. I was able to add the UM Role on the machine I used to repro your previous error. -jim

thanks. I hope someone will be able to help me on the 'deploy' newsgroup on my UM install problem. Maybe the great D.L. will arise from the pumpkin patch.... The Clinkinator

Brian,I had a different problem with Unified Messaging install and found that using Add/Remove programs in Control Panel opened a new UI that allowed me to install it.Your problem may well have a different cause but it's worth a try of the Add/Remove Programs route, I would suggest. Use the Change button.Andrew Watt MVP

Andrew, you are the man!! Must be something to do with getting it in install mode, even though I am not a terminal server. I am running Windows 2003 SP1, member server, and have enabled RDP, if that makes a difference. I would recommend that Microsoft look into it, since clearly there must be something slightly different between the Add/Remove/Change and the command-line exsetup. I suspect it is to do with install mode, and it is checking to see if it has permissions to run the MSI instead of just launching the MSI and see what happens. Thanks a ton!!! The Clinkinator....