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'

Citrix and Adobe Updater

Tired of all your users getting that message that they are not able to run the Adobe Updater every time they log into Citrix or the Citrix Desktop? Or even worse... tired of users updating your Adobe all the time on your Citrix servers? Here is a handy registry entry that will press the murder button on that Adobe Updater:

REG ADD "HKLM\SOFTWARE\Policies\Adobe\Acrobat Reader\8.0\FeatureLockdown" /v bUpdater /d 0 /t REG_DWORD /f

Note the 8.0 in that string... change it to 9.0 or whatever version you are running (best bet is to browse the registry for the specific string you need first). Don't forget to do a "change user /install" before and "change user /execute" after just to make sure.

---Update---

It seems that in some cases, that may not even be enough to stop the Adobe Updater. The final nail in the coffin, so to speak, after performing the above is to go into the C:\documents and settings\all users\ directory and hunt down Adobe_updater.exe, then rename it to .old. That should put this problem in the ground for good.