Publishing Autodiscover through ISA

This post is based more on personal experience rather than researched fact... just a heads up. May or may not work in other environments, but it was a troublesome enough discovery process that I thought it was worth sharing. The problem was that I had an ISA 2006 box publishing my Exchange 2007 access methods (OWA, RPC/HTTPS, Autodiscover, etc). And everything was working fine, except for Autodiscover. The Autodiscover process would hang while trying to get its settings through the ISA server, then give up. In the ISA logs, I could see that the requests to autodiscover.domain.com were getting rejected because they required authorization.

Here's some additional background on my environment setup:
- ISA 2006 is configured with Authentication to my internal LDAP (Active Directory) servers
- The rule publishing my Outlook Anywhere services was configured for Authenticated Users only. It included the /Autodiscover site as one of its sites to allow traffic for.
- I was using a SAN SSL certificate (from godaddy) with webmail.domain.com as its principal name, and autodiscover.domain.com as one of the SAN names.

I'll cut to the chase and explain what I did and why. I had to remove /Autodiscover from the list of accepted sites on my default Outlook Anywhere rule, then create a new rule just for Autodiscover. The new rule featured the following differences from the original rule:
- On the "To:" tab, I still had the principal name of the certificate... webmail.pih.net. However, in the "Public Name" tab I specified "autodiscover.domain.com" as the only Website/IP.
- On the Paths tab I left the default path of "/*"... you could also specify /Autodiscover, but I didn't care to.
- On the Users tab, I had to remove "Authenticated Users" and add in "All Users". This was the real trick that got autodiscover working, I think.
- I put the rule lower on the list than the rest of the rules for good measure.

Once this change was applied, Autodiscover worked like a charm. No more ISA logs barking about denied connections (still got a few failed connections, the usual error 64 and 10054 stuff... thats normal for an RPC/HTTPS connection mind you...), and autodiscover goodness all around. I noticed that now Autodiscover pops up a box asking for login credentials during its discovery process (even though I specified the same credentials already during configuration of the outlook profile), but this is a small price to pay for working Autodiscover.

I later verified this configuration with Microsoft, by the way... an ISA engineer to be specific. He did not explain why this was, but indicated it may be an Outlook Client problem... its not responding to the request from ISA to authenticate... so the rule allowed the outlook client to bypass authentication on the ISA server and authenticate directly against the exchange server instead. A slight security breach, but nothing to be terribly concerned about considering its just for Autodiscover.

Exchange Edge Server and DNS

Here's a lesson in items that should (and did) work together, but got hot fixed (pronounced hot-broken) inexplicably. Exchange EdgeSync service (which runs on your Edge server and connects to your CAS server for LDAPs information) relies on ports 50389 (internal to the box - it connects to itself) and 50636 (external, from EDGE to CAS). In a recent hotfix (KB951746) by micrsoft, DNS was also changed to reserve 2,500 random UDP ports on startup. It just so happens that the range of ports includes those of LDAP and LDAPs... you can see where this is going.

The symptoms of this problem are that

A) Your EdgeSync service will not start up, because your Exchange ADAM service will not start up.

B) You get an error in the application event log stating something to the effect of "An attempt was made to access a socket in a way forbidden by its access permissions" from the Service Control Manager service (EventID 7023).

C) No incoming email.

The fixes for this on Server 2003/2008 are as follows:

1) Open Regedit on your EDGE server and drill down to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

2) Create a new MultiString Value named "ReservedPorts"

3) In the Value box, enter 50389-50389 on one line, and 50636-50636 on another line. You could also just add 50389-50636 if you are lazy (like me).

4) Restart the server.

Voila, problem fixed.

There is an alternative on 2008 servers as well... you can simply change the "DNS Server" Service to a "Delayed Start (Automatic)" status. EDGESync ADAM should grab its ports before the DNS server does, and all proceeds merrily. There's yet another fix you can do for 2008 R2, but I won't even bother as Microsoft does not even support Exchange 2007 on 2008 R2 as of this writing... so why would you do it? :P

Exchange 2003 SP2 Install/Update Fails While installing Activesync

This is a direct rip of an article on Jeremyroe.net. Why copy instead of link? Who knows what info will be around, and for how long. :)

While performing a reinstall of Exchange SP2 I was presented with the following Error:

“Setup failed while installing sub-component Exchange ActiveSync with error code 0xC0070643 (please consult the installation logs for a detailed description). You may cancel the installation or try the failed setup again.”

I took a look in the Exchange Server Setup Progress.log and found the following errors:

[10:30:57] Calling MSXML installer with command line: “msiexec /i msxml3.msi /q reboot=”ReallySuppress”"
[10:30:57] Process created … waiting (-1)
[10:30:58] Process has exited with 0×000643
[10:30:58] The command

msiexec /i msxml3.msi /q reboot=”ReallySuppress”

failed, returning error code 1603 (Fatal error during installation.). — ID:31136 — ScCreateProcess (f:\tisp2\admin\src\libs\exsetup\hiddenw1.cxx:1821)
Error code 0XC0070643 (1603): Fatal error during installation.

After a few Google searches I found the following forum Posting Here

In short – MSXML3 is already installed on the Server – The post outlines the following steps.

1.Get a copy of the Windows Installer package for the version of MSXML 3 you have installed.
2.Place a copy inside Exchsrvr\bin
3.Rename the existing msxml3.msi to msxml3.msi.backup
4.Make a copy of the latest version MSXML Windows Installer file and rename it to msxml3.msi. This will leave you with msxml3.msi and msxml3sp?.msi (in my case msxml3sp7.msi).
5.Click Retry on the error and it should continue as planned.
In my case I didn’t show MSXML 3 Installed – I had the following packages:

MSXML 4.0 SP2 (KB927978)
MSXML 4.0 SP2 (KB936181)
MSXML 4.0 SP2 Parser and SDK
MSXML 6.0 Parser (KB33579)

I tried a number of things but eventually came to the conlusion that I did in fact have MSXML 3.0 SP7 installed and it simply did not show in add remove programs. I replaced the MSI with the download from this link:

http://www.microsoft.com/downloads/details.aspx?familyid=28494391-052b-42ff-9674-f752bdca9582&displaylang=en


After that I hit retry on the install and still had no luck – I then gave a reboot and a fresh attempt at the install a try using the updated MSI and it proceeded fine.

Windows 7 GodMode Folder

That's right, there's a 'god mode' folder. It brings back memories of good old fashioned DOOM.

The GodMode folder is actually pretty convenient for maintenance, management, and setup of a computer... its essentially just a classic collection of all control panel items at their bottom levels that you can search through... takes all the guesswork out of finding all those familiar windows XP control panel items.

All you need to do is create a new folder, then as then name, enter

"GodMode.{ED7BA470-8E54-465E-825C-99712043E01C}" (without the quotes).

You'll notice the icon will rename itself to GodMode, and the icon will change to a control panel icon. Thats all!

W3SVC1 Log Files Growing with WebDAV-Miniredir entries

One of my clients had a server with a somewhat limited C: drive. The server would occasionally fill up with log files that were hundreds of MB in size under the W3SVC folder with the same entry over and over... some kind of web request from a particular Vista machine to my server hitting WebDAV. This one plagued me for a while, but I finally sat down and traced where the error was being generated from.

According to a few internet sources, apparently there is some kind of problem with Vista and WebDAV, or more importantly Web Folders. I won't go into the details as they do not matter really... what's important is that Vista machines attempting to access a server running IIS and WebDAV may generate endless amounts of these WebDAV-Miniredir entries in your IIS logs. Eliminating whatever application is making these web requests is the key to preventing the log bloat.

In my case, the machine had Quickbooks 2009 installed, and along with it some kind of unused quickbooks web connector. The connector was set to run on startup (even though it wasn't doing anything), and thus whenever the vista machine was on it was generating a few lines of logs per second. Removing the web connector from the startup folder fixed the problem.

Installing 32 Bit Printer Drivers on a 64 Bit Windows 2008 Server

So here is a really dumb situation I found a resolution to after an hour wasted scratching my head. When installing an older printer on a Windows 2008 64 bit server and attempting to add some x86 drivers so that 32 bit workstations can print to it, Windows displays an error and asks for the "Windows Media (x86)". No CD or DVD I had contained what it was looking for... it turns out the solution was to install the printer with just 64 bit drivers, connect to it from a 32 bit windows 2008 server, and install the 32 bit drivers when prompted. After that, go to the properties of the network printer, click additional drivers, and check off the x86 box. It will upload the drivers to the 64 bit server for you. Detailed instructions below:

I created a queue for a new printer, installed the 64bit drivers and sent a test page. All was fine, so I decided to add the 32bit drivers so that some XP workstations would be able to print to it.

Each time I ticked the box, it would come up saying “Please provide path to Windows Media (x86 processor)” asking me for the ntprint.inf files from the i386 folder of the Windows media CD. Being 64bit Windows 2008, it doesn’t have an i386 folder on the media.

If you are having this issue with Windows 2008 64bit and HP drivers, here is the fix that I used below.

1. Go to a 32bit Windows Vista or 32bit Windows 2008 system and log on a user with admin rights on the print server.

2. Download the 32bit drivers you require for your printer and extract them.

3. Click on Start – run then type \\printserver (replace “printserver” with the name of your print server) and then double click on the printer, and install it. When prompted for drivers, point them to folder where you downloaded the drivers.

4. After it installs on the 32bit system, go into the local printers, right click on the network printer you just installed and choose properties, sharing, additional drivers and tick the x86 box. Click OK and the x86 drivers will upload to the server.

Credit for this one goes to: http://www.shnake.com/blog/?p=228

Removing Permissions in Exchange 2007 = Adding DENY permissons

Sometimes the most intuitive GUI based actions have strong underlying consequences. In this case, I was at a site that had an IT user whose mailbox suddenly became inaccessible. No other admins could get into it either. I began down the path of assuming this mailbox was corrupted... I disabled the mailbox thus removing it from the users account, and just out of interest, tried reattaching it to a test domain users account... it worked! The user was able to see and use the mailbox, no problem. I reattached it to the original admin... it stopped working.

Long story short, come to find, another domain admin had decided it would be more secure to go in and remove the 'domain admins' full permission to each of the admins at the site. This would only allow each admin to see their own mailbox and not eachothers. The problem with this was that Exchange 2007 implicitly adds a DENY permission whenever you remove an ALLOW permission. In this case, they removed the domain admins allow permission, so exchange 2007 added a DENY permission to the admins mailbox... thus blocking out all admins including himself.

Here is the command I used to discover this erroneous permissions entry:

get-mailboxpermission "username" | where{$_.Deny} | where{!$_.IsInherited}

This retrieves all deny permissions that are not inherited from the parent (mailstore). Low and Behold, Domain admins was listed with deny full access.

You will also notice this behavior if you look at the output of the Exchange GUI when you remove permissions... note there will be two successful commands displayed in the confirmation dialog... one to remove the permission, and one to add the deny permission. Goofy, no?

This command will remove that deny permission:

Remove-MailboxPermission -identity 'CN=User Name,CN=Users,DC=domain,DC=local' -User 'DOMAIN\Domain Admins' -Deny -InheritanceType 'All' -AccessRights 'FullAccess'