Exchange 2013 Schema Prep Objects to Object References without an Object

When running the Exchange Server 2013 Schema Prep step you may find the Exchange pre-requisites test fails, and an incredibly helpful error message is provided for your reading enjoyment:

The On-Premises test failed with the message: Object reference not set to an instance of an object.

For more information, visit: http://technet.microsoft.com/library(EXCHG.150)/ms.exch.setupreadiness.
DidOnPremisesSettingCreatedAnException.aspx

Well, actually, that was rather unhelpful. And the handy URL provided basically just says the content hasn't been added yet.

Digging in to the ExchangeSetup.log files found in C:\ExchangeSetupLogs is the only way to diagnose what's really going on. This file will list all of the pre-requisite checks the installer is running through, and if you search for the phrase 'HasException:True' you can skip to anything flagged as an issue. This would theoretically identify the exact failure and let you be on your way, right? Nope.

In my case, I ran across this exception:

Evaluated [Setting:IsHybridObjectFoundOnPremises] [HasException:True] [Value:
Microsoft.Exchange.Management.Deployment.HybridConfigurationDetection.HybridConfigurationDetectionException: The On-Premises test failed with the message: Object reference not set to an instance of an object.. ---> System.NullReferenceException: Object reference not set to an instance of an object.
   at Microsoft.Exchange.Management.Deployment.HybridConfigurationDetection.HybridConfigurationDetection.TestOnPremisesOrgRelationshipDomainsCrossWithAcceptedDomain(IOnPremisesHybridDetectionCmdlets onPremCmdlets)
   at Microsoft.Exchange.Management.Deployment.HybridConfigurationDetection.HybridConfigurationDetection.RunOnPremisesHybridTest()
   --- End of inner exception stack trace ---

Ok, so we're getting a little bit closer. You still need to do some Exchange team to real-world language translation, but the gist seems to be that the installer has an issue with the Organizational Relationships and/or Accepted Domains.

Nothing seemed obviously wrong with either of these at first glance, but after combing through each listed object in both sections about ten times I discovered a (non-functional) organizational relationship that had been defined without an Application URI value. Seems like someone had staged this object, but never completed configuration. Deleting the problematic organizational relationship allowed the installer to complete the schema prep step without any further complaints.

It sure would be nice if the Exchange installer was a bit more detailed about exactly which object it was checking or had a problem with, but who doesn't love a good Easter egg hunt from time to time?

Some notes on Lync and Exchange UM QoS

If you haven’t found it yet, the Enabling Quality of Service documentation on TechNet is a fantastic resource to get started on configuring QoS marking for Lync servers and clients. So when planning on enabling QoS in your environment you should start there, and I’d also recommend following Elan Shudnow’s posts for step-by-step screenshots of how to configure these policies on Lync servers. What I’d like to cover here is one scenario that I don’t see documented at this point – Exchange UM and Lync Edge QoS. When a remote user calls in to UM Subscriber Access or an Auto-Attendant via Lync the audio stream will not flow through the Front-End servers. Instead, it will be User <> Edge <> UM.  So if your QoS policies on the Edge don’t take UM into account you won’t have audio traffic on the Edge > UM leg of the call being tagged with a DSCP value.

To get started you can reference the Configure Quality of Service for Unified Messaging documentation. If you’ve only ever used policy-based QoS settings like Lync Server 2010 leverages then you may find the UM setup a little confusing. The key to getting UM to start marking packets is to enable the QoS feature via registry key. On each UM server you’ll want to create a new DWORD Called QoSEnabled inside HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\RTC\Transport and set the value to 1 (don’t worry if some of those sub-keys don’t exist yet – it’s safe to create them.) You can ignore the confusing TechNet note that says you should restart your Lync or OCS servers after this change. The registry key and restart applies to the Exchange UM server you just configured this registry key on – not your Lync servers.

After restarting the UM services you’ll find it will mark all outbound audio packets as SERVICETYPE_GUARANTEED. Windows defaults to applying a DSCP value of 40 for this type of traffic, but you may need to modify this to be something more standard in the networking (Cisco) world where audio is typically marked with DSCP 46. In order to do this you can either apply a Group Policy to the machines or edit the local Group Policy settings on each UM server. You can adjust this value within the Computer Configuration\Administrative Templates\Network\QoS Packet Scheduler\DSCP Value of Conforming Packets section of Group Policy.

SNAGHTML342349

Edit the Guaranteed Service Type value to match the DSCP value your network devices are expecting for audio:

SNAGHTML3472cf

At this point UM tagging of audio packets should be functional and you can (and should) verify this with a Wireshark or Netmon capture. What I’ve not seen called out is the fact that UM is just another client in the world of Lync with Edge servers and that it will be passing audio traffic through the Edge servers for remote users. UM will not respect the audio ports you limit Lync clients to, and it does not use the same range as Lync servers for audio. UM’s default port range is actually quite large since it uses UDP 1024-65535. If you’re tagging traffic from your Edge servers to Lync servers already you can simply re-use the same ports by configuring them in the msexchangeum.config file found within C:\Program Files\Microsoft\Exchange\v14\bin on each UM server.

If you’d prefer to not adjust the default port range you’ll want to be sure the UM servers are accounted for on each of your Lync Edge servers as a separate target in your QoS policy. In this example I’ve set up a separate policy towards each UM server and specified the dynamic range UM will be using as the destination port. This ensures any traffic leaving the internal-facing Edge NIC and heading towards Exchange UM will be marked with DSCP 46.

image

I also want to reiterate one point that Elan calls out since it’s not documented properly at this point – the TechNet docs suggest targeting the MediaRelaySvc.exe application in the QoS policy on the Edge servers. What you’ll find is that if you do specify an executable the packets leaving the internal-facing Edge interface will not be tagged at all. Your rule probably looks perfect and you can restart the server as many times as you’d like, but if you specify the executable you will find all packets leaving the server as DSCP 0. The workaround here is to either not specify the executable at all, or if you want to be more specific you can make sure the source IP in your QoS policy is the internal-facing NIC like I’ve done in the screenshot above.

Office 365 Migration with Cisco IronPort

I ran across an interesting issue recently where a client could not get Autodiscover to work properly during their “rich coexistence” period with an on-prem Exchange 2010 during their migration to Office 365. Autodiscover for an on-prem user would work fine, but as soon as the user had their mailbox moved to Office 365 the Autodiscover process wouldn’t work. The DNS records looked fine and when looking at the log we saw the client would connect to the internal SCP, get a redirect to Office 365 for the correct SMTP address, and then fail. We couldn’t set up a brand new profile for the user internally, but we noticed it would work perfectly ok from an Internet client. Must be something internal at that point, right?

After some more testing we learned a Cisco IronPort was being used for outbound web proxy filtering. As soon as we added an exception for the test machine's IP address we found Autodiscover worked just fine for a cloud user. In the end we added an exception for the FQDNs .outlook.com and .online.lync.com. Secure web filtering keeping users safe and admins frustrated. Happy migrating.