Wednesday, October 10, 2012

IIS Wildcard SSL Certificate Binding

Recently I had a customer who's HTTPS binding would only respond with HTTP 404 or HTTP 400 errors.  They were configuring HTTPS on their Default Web Site with a wildcard certificate as follows.

One of these things doesn't belong.
A quick curl test revealed a distinct difference between the HTTP and HTTPS bindings:

$ curl -vk http://www2.contoso.com/Login/Login.aspx >> /dev/null

< HTTP/1.1 200 OK
< Cache-Control: private
< Content-Type: text/html; charset=utf-8
< Server: Microsoft-IIS/7.5

$ curl -vk https://www2.contoso.com/Login/Login.aspx >> /dev/null

< HTTP/1.1 404 Not Found
< Content-Type: text/html; charset=us-ascii
< Server: Microsoft-HTTPAPI/2.0

You'll noted that the response headers included different responses from Server strings!  But what on earth is Microsoft-HTTPAPI/2.0?  A quick netstat reveals TCP 443 is bound to the System process at PID 4.  Isn't that the kernel or something?  Well, technically yes.  You see, the HTTP protocol in Windows is served from the http.sys driver (which is a hidden device in Device Manager).

It turns out that the way to avoid that server response is to remove the host name binding.  When IIS can't match the request to a binding, it dumps out at the driver level with the above HTTP 404 from Microsoft-HTTPAPI/2.0.

Lesson learned: if it isn't DNS, blame bindings.

Wednesday, March 14, 2012

Revenge of the LegacyExchDN


After using the PST migration method to divest an Exchange deployment, we discovered that a user couldn't act as a delegate for old items in another user's calendar.

Instead, we received this pleasant message from Microsoft:

No, it's not helpful, Microsoft.
Invoking the following didn't achieve the desired results:
Set-Mailbox -Identity Cheryl -GrantSendOnBehalfTo Natalee
And neither did:
Set-MailboxPermissions -Identity Cheryl -User Natalee -AccessRights SendAs
(Of course on Exchange 2010, you'll need to set the equivalent via AD Cmt-lets)
Set-MailboxPermissions -Identity Cheryl -User Natalee -AccessRights FullAccess
No go there either.  How about delegate permissions?
Add-MailboxFolderPermission -Identity Cheryl:\Calendar -User Natalee -AccessRights Editor
Nope.

So what's wrong and how do we go about finding out?  Being a datahead, I grabbed the latest MFCMAPI build and deployed in on a machine with Outlook installed.  With the proper permissions temporarily in place, I drilled into the user's information store, down to the calendar, then enumerated contents.

Object DN resolution failure
There I located the troubled appointment by Subject, and found that the following properties were pointing at the legacy domain's DN.


I had heard rumors of a solution leveraging X500 addresses, a relic from long, long ago.  Updating X500s would allow the metadata to resolve off of my modern Exchange 2010 deployment.

Leveraging ADModify as perscribed in the article resolved the issue.  Now, if you didn't get your mailNickname property identical between domains, you'll have to modify users individually.  Or if the old domain isn't available for reference, you'll need to use MFCMAPI to track down troublesome messages to find the exact DN that can't resolve off of the new AD deployment.

Digging up legacy DNs on known bad calendar objects

Wednesday, February 22, 2012

Forcefully Migrating a Public Folder Hierarchy

A Failed Inheritance

A few days ago, I went to mail enable a public folder for a customer and found that while it showed up great in the EMC, we couldn't deliver mail to it.  Rather, the server would respond:

#< #5.2.0 smtp;554 5.2.0 STOREDRV.Deliver.Exception:ObjectNotFoundException; Failed to process message due to a permanent exception with message The Active Directory user wasn't found. ObjectNotFoundException: The Active Directory user wasn't found.> #SMTP#

Knowing that we're talking about the GAL and/or OAB at this point, I went to rebuild the OAB ahead of schedule.  But the OAB fired back, "I can't generate!"  It was configured to generate in public folders and for web-based distribution.  Doing some thinking, I jumped into ADSIEdit and discovered that my public folder hierarchy was still pointing at the legacy server in the Exchange administrative group.

Ruh-roo, Shaggy!

What's interesting is that the OAB generation was occurring on my new server and was targeting the public folders database on the new server.  So what's wrong with this picture?

He's Responsible

Sure enough, my legacy server isn't in the DN, but I wasn't like I could turn it back on.  The object was deleted from the Exchange administrative group and the physical hardware had been sent to the dump months ago.

Looking at the Folder Hierarchies in both administrative groups revealed that the hierarchy object was in the old administrative group, but not on the new one.  That's right a server that didn't existing anymore was responsible for maintaining the MAPI PF tree for my new Exchange server.

So what to do?  Ideally, my old box would be on, with public folder replication completed and nothing but system objects in the public folders.  One right click and I could migrate this via the UI.  Checking some properties and running an Exchange Best Practices Analyzer, I discover I have the following condition: http://technet.microsoft.com/en-us/library/aa996485(EXCHG.80).aspx

Okay, so far so good.  But now the MAPI tree doesn't yet exist on my new Exchange server.  A little more digging and I discovered how my Configuration partition should look like this for a good migration:  http://social.technet.microsoft.com/Forums/ar/exchangesvrmigration/thread/c0634d0e-80aa-4988-9a0f-67f1b02b3b50

Who's On First?

Now that I've survived the above article and bounced my Information Store service, I've got 2 MAPI trees and fail the Exchange Best Practices Analyzer.  Oh, and Public Folders won't show up in Outlook Web Access.  Microsoft's got that covered:  http://technet.microsoft.com/en-us/library/dd535370(EXCHG.80).aspx

Once that's in place and I've confirmed I'm not getting NDR's things look great.  Oh wait, Message Tracking shows that my message is received but never hits the mailbox store.  A glance at the Queues, and my message is in the Unroutable Queue.

Remember our screenshot above?  There's still a routing group connector on the legacy administrative group side, but not on the production site.  Yes, that'll be a delete in ADSIEdit. You backed up all of this first, right?

Final Absolution

And now my public folders are managed by the new system and the old metadata is gone.  Just one more email test.  And:
#< #5.2.0 smtp;554 5.2.0 STOREDRV.Deliver.Exception:ObjectNotFoundException; Failed to process message due to a permanent exception with message The Active Directory user wasn't found. ObjectNotFoundException: The Active Directory user wasn't found.> #SMTP#
What?  Still?  Now we're back in familiar territory.  This happens quite frequently in Exchange 2003 to Exchange 2010 migrations.  It's a documented solution: http://blogs.dirteam.com/blogs/davestork/archive/2010/03/16/mail-enabled-public-folder-recipient-not-found.aspx

And with that, upgrading the GALs to the new 2010 format and an OAB update and I can finally use mail-enabled public folders in Exchange 2010.

Remember, your mileage may vary!  Backups are important, to the point of considering PST exports of the Public Folders as an additional failback.  The best part is, this is documented, but there are several pieces we had to put together, but with a good understanding of the schema and using ADSIEdit and the issue became obvious and we had a path to resolution.

Friday, February 17, 2012

Slow Printer?

Fighting with a slow printer?  Here's some item to check that may improve your performance.

Drivers, Drivers, Drivers

Are you running the latest driver from the manufacturer?  If your PDF files are getting mangled or crashing your application, are you using a PostScript driver or PCL?  Try a different flavor.

Memory

Does your printer have expandable memory?  You can consider adding memory, or using a front-end server for ripping. But, make certain your driver is configured to use the full memory of your device, or that your spooling options at the driver level rip appropriately for your configuration.

Print Processor

A new technique I discovered is the importance of the print processor.  Buried deep within the driver's Advanced settings, you'll find the Print Processor selection as show in the screenshot below.

Deep within the print driver settings

I've recently had a driver default to the winprint.  This slowed ripping significantly.  Switching to one of the native HP based items improved rip speed significantly.  Your mileage may vary.

Happy printing!