Blog: Exchange 2010

While trying to install Exchange 2010, the process failed with the following error:

Organization Preparation Failed

Error:

The following error was generated when "$error.Clear(); install-ExchangeSchema -LdapFileName ($roleInstallPath + "Setup\Data\"+$RoleSchemaPrefix + "schema0.ldf")

" was run: "There was an error while running 'ldifde.exe' to import the schema file 'C:\Windows\Temp\ExchangeSetup\Setup\Data\PostWindows2003_schema0.ldf'. The error code is: 8224. More details can be found in the error file: 'C:\Users\administrator.{your-domain}\AppData\Local\Temp\2\ldif.err'".

There was an error while running 'ldifde.exe' to import the schema file 'C:\Windows\Temp\ExchangeSetup\Setup\Data\PostWindows2003_schema0.ldf'. The error code is: 8224. More details can be found in the error file: 'C:\Users\administrator.{your-domain}\AppData\Local\Temp\2\ldif.err' [more]

A quick try again and it failed at the same spot. Fortunately, a friendly blogger had run into a similar situation and provided some workarounds - http://www.petenetlive.com/KB/Article/0000442.htm

Basically, we need to run the organization prep tasks manually. I logged onto the Schema Master with my setup DVD attached and ran “Setup.exe /PrepareSchema” and then “Setup.exe /PrepareAD”. Now, since the Schema work has already been taken care of, when I ran the Exchange 2010 setup on the new server, it passed those checks easily and allowed me to continue the install.

1. Open the Exchange Management Console
   • Make sure you are using an Administrator account
2. Open the Web Management Interface
   • Click Toolbox > Message Tracking
   • Use the same Administrator account details to login
3. Choose the User to manage
   • In the top-left corner you should see a link that says 'Manage My Organizaiton'; hover over this link and click on 'Select User' from the drop down
   • From the list, search and select the User's name
4. Edit the user's out of office message
   • A new window/tab should open with basic management options for that user; on the right-hand-side there are a list of shortcuts, click 'Tell people you're on vacation'  This will give you access to both internal and external messages
   • Once complete, remember to save everything and log out

 Spiceworks Article: http://community.spiceworks.com/how_to/show/8375-edit-another-user-s-out-of-office-message-in-exchange-2010-without-editing-permissions

I have been working on migrating a customer from Exchange 2003 to Exchange 2010. I had already moved all the mailboxes, public folders, and all the inbound/outbound email routing to the Exchange 2010 servers. I enabled SMTP logging on the Exchange 2003 server so that I could detect any other devices out there on the network that may have been routing email through the old Exchange 2003 server. I reviewed it off and on for a week or so and noticed a small volume of SMTP traffic was being recorded inbound from the Exchange 2010 servers. I didn’t pay much attention to the actual to/from addresses or the payload at the time assuming it was probably public folder replication. [more]

A few days later, after removing all the public folder replicas from the Exchange 2003 server, I was still seeing this traffic so I started to look at it more closely. What I was seeing was inbound SMTP traffic from the Exchange 2010 servers with a from address being one of a handful of distribution lists. Then, the Exchange 2003 server would turn around and send email to the Exchange 2010 servers to each individual email addresses in the distribution list. After a fair amount of digging I discovered the issue. At some time in the past, the customer had manually designated distribution list expansion servers in the AD properties of the distribution list.

Using ADSI and one of the problematic distribution groups, I was able to find a property defined on the distribution group called msExchangeExpansionServerName. For all distribution groups getting routed back and forth between the Exchange 2003 and 2010 servers, this field was populated with the value of the old Exchange 2003 server. Why you would define this property on the distribution group in an environment with one Exchange server, I have no idea. However, a quick powershell script fixed the issue:

Get-DistributionGroup | where {$_.ExpansionServer -ne "$null"} | set-distributiongroup -ExpansionServer $null

A while back when I was setting up a new Exchange 2010 environment, I had just finished getting the new Unified Messaging server online and had begun testing. One of the issues I ran into was when I tried to administratively reset someone’s PIN. As usual, I’d go into the EMC, find the mailbox, right-click, and choose Reset PIN. Then I’d let it auto-generate one and send the email. Except it wouldn’t send the email. In the application log, I would see something like:

"E:\Program Files\Microsoft\Exchange Server\V14\UnifiedMessaging\voicemail\048696bb-3475-41d8-b497-b839c9e1daa8.txt". Error details: "Microsoft.Exchange.UM.UMCore.SmtpSubmissionException: Submission to the Hub Transport server failed. The operation will be retried. ---> Microsoft.Exchange.Net.ExSmtpClient.UnexpectedSmtpServerResponseException: Unexpected SMTP server response. Expected: 220, actual: 500, whole response: 500 5.3.3 Unrecognized command

In the end user’s mailbox, they would not receive an email in the inbox with their new PIN; however, it occasionally would appear in the Drafts folder as if Exchange had composed the email, but had forgotten to hit Send. [more]

They say hindsight is 20/20. I believe it.

Turns out, none of the receive connectors in Exchange allowed for Exchange Server Authentication. Whoops!

I’ve been working on migrating an Exchange environment to 2010. This process includes an upgrade to the Unified Messaging role of Exchange to 2010 as well. We had purchased a UCC certificate to include all the Subject Alternate Names our Exchange environment would need and I had already applied it to the CAS server successfully. Since this certificate also included the FQDN of our UM server, I added the cert. and assigned the UM service to it so that Exchange could start processing voicemails through 2010 instead of 2007. [more]

After I had moved a couple of mailboxes (including mine) over for testing, I discovered that I could no longer receive voicemail. People were redirected to the Subscriber Attendant instead of my individual mailbox. There were events logged on the UM server saying the following:

Event ID: 1400 Source: MSExchange Unified Messaging
The following UM IP gateways did not respond as expected to a SIP OPTIONS request. Transport = TLS, Address = lync.ourdomain.com, Port = 5061, Response Code = 0, Message = This operation has timed out.

After considerable troubleshooting, I ran across a forum posting (http://social.msdn.microsoft.com/Forums/en-US/communicationsserversdk/thread/2733adf2-c91b-4b94-bf43-be93cdd2d5ef/) from someone who encountered the same issue and called for a support incident with Microsoft to figure out what was going on. In order for UM to work in a Lync phone system environment, the Subject Name of the certificate installed must be the FQDN of the UM server itself. It won’t work if it’s just included as a Subject Alternate Name; it must be the Subject Name.

I generated a new certificate from our internal CA with the UM server as the SN of the certificate, installed and assigned it to the UM roles (leaving our UCC cert running the remaining roles), and immediately started receiving voicemail notifications.

I found one other blog posting after the fact that backed this claim up even more (http://therealshrimp.blogspot.com/2012/03/multiple-exchange-um-servers-and.html).

We recently became aware of a problem with Exchange 2010 users being unable to set their out of office settings.  With their legacy Exchange 2003 mailboxes, they could set out of office.

When trying to set out of office within Outlook, users would get an error message that the Exchange server could not be contacted.  Performing the “Test e-mail autoconfiguration” kept failing to connect to the server with HTTP status code 401 Unauthorized.  It was also noted that OWA would not allow logins because the login credentials would not work for anyone.

After trying to troubleshoot permission problems within IIS of the mail server, I eventually came across this thread:[more] http://social.technet.microsoft.com/Forums/en-US/exchange2010/thread/36662e7c-8c4a-44dc-85d9-eb7fab1d8b49/

I ran powershell as an administrator on the server, and typed in the following:

• Import-Module ServerManager
• Add-WindowsFeature NET-Framework,RSAT-ADDS,Web-Server,Web-Basic-Auth,Web-Windows-Auth,Web-Metabase,Web-Net-Ext,Web-Lgcy-Mgmt-Console,WAS-Process-Model,RSAT-Web-Server,Web-ISAPI-Ext,Web-Digest-Auth,Web-Dyn-Compression,NET-HTTP-Activation,RPC-Over-HTTP-Proxy

It appears that this command re-imports many IIS modules.  In the article, it has a –restart at the end, but I left it off to prevent the server from rebooting.  It was not necessary in my case in order to resolve all of the issues with OWA/OOF/Autoconfiguration.

I am working on a large upgrade of Exchange 2007 to Exchange 2010 at one of our customers. One of the “to-do” items is to check and make sure that all of the exchange web services are healthy. The issue that I ran across was a discrepancy between what the powershell command for testing the EWS returned and what Outlook returned. The powershell command to test all EWS is the following: [more]
 
[PS] D:\Documents and Settings\cnx_user\Desktop>Test-OutlookWebServices | fl
Id      : 1003
Type    : Information
Message : About to test AutoDiscover with the e-mail address cnx_user@mydomain.com.
Id      : 1006
Type    : Information
Message : The Autodiscover service was contacted at https://server.domain.dom/Autodiscover/Autodiscover.xml.
Id      : 1016
Type    : Success
Message : [EXCH]-Successfully contacted the AS service at https://server.domain.dom/EWS/Exchange.asmx. The elapsed time was 296 milliseconds.
Id      : 1015
Type    : Success
Message : [EXCH]-Successfully contacted the OAB service at https://server.domain.dom/EWS/Exchange.asmx. The elapsed time was 0 milliseconds.
Id      : 1014
Type    : Success
Message : [EXCH]-Successfully contacted the UM service at https://server.domain.dom/UnifiedMessaging/Service.asmx. The elapsed time was 171 milliseconds.
Id      : 1006
Type    : Success
Message : The Autodiscover service was tested successfully.
 
Ok, so it looks like everything was working as expected, until I tried testing from Outlook under my account. Outlook hides the “Test Email AutoConfiguration” option well. You have to hold down CTRL and right-click the Outlook icon in the system tray to see the option. This option basically testing the EWS. Uncheck the “Use Guesssmart” and “Secure Guesssmart Authenication” options, put in your password and click Test. I kept getting this error on the log tab.
 
Autodiscover to https://server.domain.dom/Autodiscover/autodiscover.xml FAILED (0x800C8203)
 
I spent a good half hour trying to figure out what might be wrong when I finally realized that the EWS testing tool was using my username (cnx_user) followed by the AD domain. See below:

Well, it just so happens that this customer does not deploy two aliases per user mailbox (user@ad_domain & user@public_domain) as is the default for Exchange. Their default address policy only configures the public-facing alias on all mailboxes which is cnx_user@mydomain.com. The Outlook EWS tools was using an alias that didn’t exist... changing it to cnx_user@mydomain.com instead of cnx_user@domain.dom solved the problem.

The Microsoft Exchange team is an interesting group. For years, it seemed like they didn’t listen to any user feedback about the product. The GUI was way too complicated and automation procedures were difficult because there was not a convenient CLI for the product. When Exchange 2007 came out, even though the GUI lacked a little functionality, the product as a whole was way better and it incorporated a lot of feature requests that Exchange admins have been asking for. Most notably, the LCR, CCR, and SCR features that allow local HA and DR for Exchange with a lot less complexity than past versions.

Now, enter Exchange 2010. Exchange 2010 takes everything that we were introduced to in Exchange 2007 on the availability side (LCR,CCR, SCR) and removes it. Yep, removes it. All the availability features have been merged into one technology called Database Availability Groups (DAGs). DAGs have a really nice feature set on paper…I say on paper because I haven’t really implemented them in practice, but the one deal killer at least for most of our customers is that DAGs REQUIRE Enterprise Edition OS licenses. [more]The reason is that DAGs still depend on pieces of Microsoft Cluster Services. This kinda stinks because in Exchange 2007 you could implement database HA with LCR and DR with SCR and never buy any Enterprise licenses. Like I said, the Exchange team is an interesting group….I wonder if they discussed this and decided...”that’s no big deal…doesn’t everyone have Enterprise volume licensing”.