Exchange 2010 WinRM and Powershell

Situation

Opening the Exchange Management Shell (EMS) on the server fails to connect to the local server with this error:

Connecting to remote server failed with the following error message : The WinRM client received an HTTP server error status (500), but the remote service did not include any other information about the cause of the failure. For more information, see the about_Remote_Troubleshooting Help topic.

Nice, huh?  Looking at the event log gave me an RBAC error and a a few others as shown…

(Process w3wp.exe, PID 3244) "RBAC authorization is unavailable due to the transient error: The Microsoft Exchange Active Directory Topology service on server localhost can't be contacted via RPC. Error 0x5."

Process w3wp.exe (PID=3244). An remote procedure call (RPC) request to the Microsoft Exchange Active Directory Topology service failed with error 5 (Error 0x5 (Access is denied) from HrGetServersForRole). Make sure that the Remote Procedure Call (RPC) service is running. In addition, make sure that the network ports that are used by RPC are not blocked by a firewall.

Process w3wp.exe (PID=3244). An remote procedure call (RPC) request to the Microsoft Exchange Active Directory Topology service failed with error 5 (Error 0x5 (Access is denied) from HrGetServersForRole). Make sure that the Remote Procedure Call (RPC) service is running. In addition, make sure that the network ports that are used by RPC are not blocked by a firewall.

What changed over the last week?  E2010 SP2 and RU1 had been run into the environment – but nothing else.

This was very frustrating because all the “normal” fixes to this did not work.  WinRM extensions, Kerberos auth on the powershell vdir, rebooting, you name it, I looked at it.  Nada.

The Fix

On a whim, while checking the PowerShell virtual directory path, and comparing a working server to this non-functioning server, I looked at the application pool…oh &%*!.  How did it get that way?  Four hours of chasing my tail.  Four hours of my life I cannot get back.

My only thought is that SP2 or SP2 RU1 borked that setting for some bizarre reason.  Here is a nice screen shot of what it was…

…and what it should be:

YMMV

0x2114 schema update failed

Subtitle: Fun with linkID and Schema LDF files

Scenario

On site getting a project rolling.  One of our first steps was to test the schema extending in lab.  Perfect execution.  So we submit for change control and get going the next morning.  Having just succeeded doing this task the day before in lab, we were not expecting any issues. Not so fast Bucko! 

Setup /prepareschema (setup /ps) got about 20 seconds in and dumped out with this little gem:

[02/09/2012 19:08:14.0737] [1] [ERROR] There was an error while running 'ldifde.exe' to import the schema file 'C:\Windows\Temp\ExchangeSetup\Setup\Data\PostExchange2003_schema18.ldf'. The error code is: 8245. More details can be found in the error file: 'C:\Users\me.adm\AppData\Local\Temp\5\ldif.err'

Oh wonderful.  But, no problem – let’s get to the bottom of this and get moving forward.  A closer read revealed that the ldf count was up to at least the 18th file, and probably higher.  (If you look at that directory, there is over 400 LDF files there….)  So, my conclusion is that something is not the same in the production AD as in the lab.  Looking at the ldif.err file shows this: (sorry about the crappy wrapping…)

Entry DN: CN=ms-Exch-Mobile-Mailbox-Policy-Link, CN=Schema, CN=Configuration,DC=domain,DC=local

Add error on entry starting on line 358: Unwilling To Perform

The server side error is: 0x2114 Schema update failed: An attribute with the same link identifier already exists.

The extended server error is:

00002114: SvcErr: DSID-032603BC, problem 5003 (WILL_NOT_PERFORM), data 8468

An error has occurred in the program

Personally, I really liked the idea of changing the error code in the file I was told to go look at… the server error said 8245, here in the ldif.err file we are given a value of 8468.  This is important though… it enabled me to find an EXACT fix.

What was Wrong

Long story short – at some point in the past, the client had done an application or something that grabbed the same linkID that the Exchange 2010 schema extension wanted to use.  So it pitches the error and quits out.  Here is the pertinent section of the ldif.log:

[02/09/2012 19:08:14.0284] [2] Beginning processing install-ExchangeSchema - LdapFileName: 'Setup\Data\PostExchange2003_schema18.ldf'

[02/09/2012 19:08:14.0284] [2] Running <C:\Windows\system32\ldifde.exe> with arguments <-i -s "XXX-W2K8-DC02.domain.local" -f "C:\Windows\Temp\ExchangeSetup\Setup\Data\PostExchange2003_schema18.ldf" -j "C:\Users\me.adm\AppData\Local\Temp\5" -c "<SchemaContainerDN>" "CN=Schema,CN=Configuration,DC=domain,DC=local">.

[02/09/2012 19:08:14.0705] [2] Process C:\Windows\system32\ldifde.exe finished with exit code 8245.

[02/09/2012 19:08:14.0721] [2] [ERROR] Unexpected Error

[02/09/2012 19:08:14.0721] [2] [ERROR] There was an error while running 'ldifde.exe' to import the schema file 'C:\Windows\Temp\ExchangeSetup\Setup\Data\PostExchange2003_schema18.ldf'. The error code is: 8245. More details can be found in the error file: 'C:\Users\me.adm\AppData\Local\Temp\5\ldif.err'

What is happening here?

The Fix

0x2114 schema update failed: searching that phrase or “an attribute with the same link identifier already exists” gave some interesting results – including this one:  http://support.microsoft.com/kb/917682 which is for Exchange 2003 and the advice is to modify the ldf file with an arbitrary number and, of course, in the future hope that no one created an install that wants to use that number for a LinkID.  After reading that article and several others like it, I concluded that the error was the same, but I did not like the solution.

Searching with the second value in the ldif.err log (8468) gave me a technet forum article that was so close to being my error that I was almost moved to genuflect in the direction of Redmond.  Here is the article.  Down towards the bottom is the interesting part, where is mentions “…German article which exactly described my problem…” BINGO!!  Anyone read German?  My search engine does….

For you bilinguals, here is the original and here is the translation.

The LinkID exists that the PostExchange2003_schema18.ldf file wants to use for ITS object is already in use.  OK.  Let’s look at the actual file, or at the very least a section of the file (it is several K of text).

In my case, the exchange install log pointed at this attribute inside the PostExchange2003_schema18.ldf as failing:

dn: CN=ms-Exch-Mobile-Mailbox-Policy-Link

A quick search of the PostExchange2003_schema18.ldf  file give us this section:

dn: CN=ms-Exch-Mobile-Mailbox-Policy-Link,<SchemaContainerDN>
changetype: ntdsSchemaAdd
adminDescription: ms-Exch-Mobile-Mailbox-Policy-Link
adminDisplayName: ms-Exch-Mobile-Mailbox-Policy-Link
attributeID: 1.2.840.113556.1.4.7000.102.50668
attributeSecurityGuid:: iYopH5jeuEe1zVcq1T0mfg==
attributeSyntax: 2.5.5.1
isMemberOfPartialAttributeSet: TRUE
isSingleValued: TRUE
lDAPDisplayName: msExchMobileMailboxPolicyLink
name: ms-Exch-Mobile-Mailbox-Policy-Link
oMSyntax: 127
oMObjectClass:: KwwCh3McAIVK
objectCategory: CN=Attribute-Schema,<SchemaContainerDN>
objectClass: attributeSchema
linkID: 1058
schemaIdGuid:: KqC15oH1QkyuYBCP58HttQ==
searchFlags: 0

(The DN: line, btw, is line 358 which is what the ldif.err log pointed to also.)

But, look at the “linkID: 1058” line… and then go back and read the German translation again.  And there is our fix.  We need to get a number into that value that no longer conflicts… but we want that number to be good from here on out also.  What is important about that German article is that it gives us the input for the value – but in AD terms without having to dream up a number and hope it never gets used, or contact Microsoft for an official linkID to use (something maybe the Exchange team did?)!  Apparently, using this number    (1.2.840.113556.1.2.50) causes the object to get created with a linkID that does not exist.  Sweet!

For a quick close to this issue, we copied the entire DVD down local, cranked up a quick notepad session, changed the linkID in question to the 1.2.840.113556.1.2.50 value, and re-ran setup /ps.  Success.

Keep in mind that you need to be very careful about editing the LDF files, much like AdsiEdit, what you do is quick and fairly permanent.

YMMV

Update: Lync for Mac 2011 - Managed Preferences

Nlow here we have something very useful.  With the increased usage of the Apple Mac platform (I recently did a project that was over 50% Mac on the desktop) managing Lync clients on the Mac becomes increasingly important.  Microsoft has released updated guidance.  See the entire NextHop article here.

PIC Provisioning Guide

Do you need help setting up the PIC feature in Lync or OCS?  Here is a great resource – no need for me to re-write it!

http://www.microsoft.com/download/en/details.aspx?id=14966

YMMV.

Exchange 2010 CAS OWA Re-direct

Situation

A client asked me to simplify the OWA URL so that the users (who apparently cannot learn new methods or change their shortcut) would not have to actually type HTTPS or /owa but instead just be able to blindly enter mail.company.com and have it work.  Pretty easy, eh?  Not so, as it turns out.

Yes, I know all about how to “Simplify the Outlook Web App URL”  - I also needed to create a deny and redirect on the TMG layer to cover those users who were outside the firewall.  For the TMG layer I follow fellow MVP Richard Hicks blog article.  Tastes great and is less filling.  For the CAS layer, I follow the Brian Desmond article.  Also tastes great and is equally less filling.

With all that expert help behind me, you’d think I was done early that night, eh?  Not.

What Happened

Normally,  I just step through the well-documented process from the CHM/online help, and  double check myself with the Desmond blog, and es finite!  Not this time.  As it turns out (as the stomach churns) the web.config in the C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\Owa folder (your install dir may be different) was not updating properly.  Odd.  No matter what I did, the /exchange, /public/ and /ExchWeb vdir’s would not stay redirected as needed, and the /owa vdir kept getting a redirect also – which results in a redirect loop – and this is not good.

I noticed that the web.config file (previously mentioned above) did not have the expected lines… what I had was this:

Nothing!

I went around this several times.

The Fix I Used

I toggled the /owa to this:

Which, after an iisreset /restart gave me this in the web.config file:

<system.webServer>
    <httpRedirect enabled="false" />
</system.webServer>

Based on this forum article, I was expecting to see this:

<system.webServer>
  <httpRedirect enabled="true" destination="/owa" exactDestination="false" childOnly="false" httpResponseStatus="Found">
  </httpRedirect>
</system.webServer>

Well, says I, it ain’t right.  So, I did a little cut n paste and inserted that into my web.config file.  Then did an iisreset /restart again.

As expected, the /OWA vdir was marked to redirect:

As were the /exchange, /exchweb, and /public (as they are needed that way).

Hmmm.  OK, if manual methods are needed, I am all for it.  I went back to the web.config file and removed those lines I just put in there… and did another iisreset /restart.  and voila!

Why I had to jump through the hoops like this I do not know, but these screen shots are from my lab, which is identical in build to the client (gotta love those labs) and I reproduced it step for step.

FWIW, Pat Richards has a script on his blog that would appear to fix this also.  Also, remember that when you do this, the OAB is going to broken and to fix that you need to add the “authenticated users” group to the /oab/webconfig file as shown here.

YMMV.