I recently wrote a blog about installing Exchange 2010 SP1 and the prerequisites that must be installed on each Exchange 2010 Server before SP1 will install correctly. In that article I also mentioned that I had not experienced any issues with Exchange 2010 SP1. I now have one issue with Exchange 2010 SP1 to report.
I am currently assisting one of my customers with an 8-Server Exchange 2010 deployment. This environment consists of 4 HUB/CAS Servers and 4 Mailbox Servers. Since this was a new deployment, we chose to install Exchange 2010 SP1 on all Exchange 2010 Servers before migrating any users from their legacy Exchange 2003 environment. The SP1 installation completely successfully without issue on all 8 Exchange 2010 Servers. Of the 8 servers, 7 are functioning correctly. However, one HUB/CAS Server now displays the following error when launching the Exchange Management Console:
The following error occurred when retrieving user information for ‘DomainUserID’:
Unexpected error [0x1EEC6758] while executing command ‘Get-LogonUser’
The user account in question is a member of the Organization Management group and has no issue running the EMC on any other Exchange 2010 Servers within the environment. If a different user who belongs to the Exchange Management group logs into the same server, the error does not occur. We are currently working with Microsoft Premier Support to help find resolution to this issue. According to the technician that we’ve been working with at Microsoft, this is a known bug that sometimes occurs in multiple Domain environments. In our case, however, our environment consists of a single Active Directory Domain. I expect that Microsoft will come up with a fix for this issue sometime over the next few weeks and pass it along to us. When they do I’ll be sure to update this blog entry with the fix information.
Until a fix is available, there are two workarounds to this issue:
I am currently assisting one of my customers with an 8-Server Exchange 2010 deployment. This environment consists of 4 HUB/CAS Servers and 4 Mailbox Servers. Since this was a new deployment, we chose to install Exchange 2010 SP1 on all Exchange 2010 Servers before migrating any users from their legacy Exchange 2003 environment. The SP1 installation completely successfully without issue on all 8 Exchange 2010 Servers. Of the 8 servers, 7 are functioning correctly. However, one HUB/CAS Server now displays the following error when launching the Exchange Management Console:
The following error occurred when retrieving user information for ‘DomainUserID’:
Unexpected error [0x1EEC6758] while executing command ‘Get-LogonUser’
The user account in question is a member of the Organization Management group and has no issue running the EMC on any other Exchange 2010 Servers within the environment. If a different user who belongs to the Exchange Management group logs into the same server, the error does not occur. We are currently working with Microsoft Premier Support to help find resolution to this issue. According to the technician that we’ve been working with at Microsoft, this is a known bug that sometimes occurs in multiple Domain environments. In our case, however, our environment consists of a single Active Directory Domain. I expect that Microsoft will come up with a fix for this issue sometime over the next few weeks and pass it along to us. When they do I’ll be sure to update this blog entry with the fix information.
Until a fix is available, there are two workarounds to this issue:
- Use the Exchange Management Shell instead of the Management Console to manage any servers exhibiting this issue
- Use an alternate account to perform administrative tasks using the Exchange Management Console on servers exhibiting this issue
The reason we initially contacted Microsoft on this issue is because we feared that this error could be symptomatic of a deeper problem with our server or with Service Pack 1. Microsoft has assured us that this is a minor user interface bug and is not representative of deeper issues with our server. We’re taking them at their word on this issue and proceeding with our deployment and migrations using the workarounds I mentioned above. I’ll update this blog when we hear back from Microsoft or if we find another fix.
