Upgrading VMware ESX 4.1 guests to ver. 7 hardware

This is pretty straight forward, but thought I would log my process just in case I totally forget down the road.

First, you can check the version of the virtual machine by going into the 'edit settings' dialogue and looking in the top right hand corner. Version 7 is the latest and greatest.

1) Install the upgraded vmware tools and reboot the server
2) Shut down the guest after it reboots
3) Right click on the guest in the VMware console and select 'Upgrade Virtual Hardware'
4) Remove the old NIC card and add a fancy new VMXNET3 connection. You may want to make a note of your network config if you don't know it.
5) Start up the VM, and once in windows, configure the network settings.
6) Wait for the hardware to finish installing, reboot once more, and done!

Fixing poor video performance on ESX 4.1

Apparently there is some kind of bug for ESX 4.1... windows 2008 servers have terrible console video performance on the new platform, regardless of updating the vmware tools. The quick fix for that one is to go into device manager and replace the drivers on the display adapter. Specify your own drivers, browse to c:\program files\common files\vmware\drivers\wddm_video\ and specify the vm3d driver in there. Reboot and voila, console performance returns.

Renewing Exchange 2007 Self-Signed SSL Certificates

I already knew what needed to happen to fix this issue, but in Microsoft's infinite wisdom they saw fit to require 14 steps and intricate knowledge of their edgesync service in order to complete this yearly (and after SP2 every 5 year) service on Exchange 2007.

Symptoms: Errors in the exchange 2007 hub server indicating that the SSL certificate is expired. I saw event ID 12015 and 2019, both mumbling something about direct trusts, expiration, and so such. You may see others. Your mail flow also probably stopped.

Problem: The self signed cert that was created during the installation of exchange 2007 has expired. By default, the cert only lasts 1 year. After installing SP2, they upped the expiration length to 5 years.

Soluiton: Renew the cert on both the edge and hub server, recreate the edge subscription, restart the adam service, run the start-edgesynchronization command, then retry the queue on the edge server.

Details:

You may see the following error in the queue viewer on your edge server:
451 4.4.0 Primary target IP address responded with: "454 4.7.5 Certificate validation failure."

Open the exchange powershell on your hub server and run:
get-exchangecertificate

You should get a list of all the SSL certificates currently in use, and what they are doing for you. Then, run:

get-exchangecertificatae | fl

This will show you a detailed view of each certificate. Look for the one that says 'invalid' or 'expired' next to Status. Make a note of the thumbprint of that certificate, or better yet copy it in the shell.

Run the following command to renew that certificate. All it really does is make a new certificate that is enabled for the same services the old one was:
Get-ExchangeCertificate –Thumbprint “thumbprint of expired certificate” | New-ExchangeCertificate

Now, go back in and remove the expired certificate by running:
remove-exchangecertificatae -thumbprint "thumbprint of expired certificate"

Do these same steps on your edge server.

Create a new subscription file by opening the console on your edge server and typing:
New-EdgeSubscription -File "c:\subscription.xml"

Back to the Exchange Server:

Copy the subscription file from your Edge machine to your local hard drive.

Open the Exchange Management Console and create a new Edge subscription. Don't delete the existing subscription, leave the defaults, and all of your send/receive connectors will remain intact:
Organization Configuration -> Hub Transport -> New Edge Subscription... -> Browse to subscription.xml and leave "Automatically create a Send Connector" checked.

From the PowerShell on the hub server, synchronize your Edge subscription:
Start-EdgeSynchronization

Receive your queued messages:

Open the queue viewer on your Edge box and retry all of the messages. If you have Outlook open, you should see your Inbox fill right up!
Send any queued messages:

Open the queue view on your Exchange box and retry all of the messages. You may receive the following error. If you do, just give it some time, I checked my queue about 20 minutes later and they had all been sent.
451.4.4.0 Primary target IP address responded with: “454.4.7.0 Temporary authentication failure.”

Excerpts taken from (http://www.bunkerhollow.com/blogs/matt/archive/2009/06/11/exchange-2007-edge-queue-4-7-5-certificate-validation-failure.aspx)

Windows 7 Sharing Fix

There is nothing quite so humbling as bashing your head against a workstation for hours trying to figure out why the damn thing won't access a simple network share. Sure, there are a lot of specifics to the problem, but all the same... anyway, here's what I was up against:

- Two fresh windows 7 installations, all the latest updates (as of 2/23/2010)
- Workgroup machines, not in the same workgroup
- One has a Everyone share, with restricted NTFS permissions
- Neither machine can access eachother's c$ or admin$ shares

I am not sure which of the following steps fixed it... but I did all of them, and it's working now... so take that for what it is worth:

click the start button and type secpol.msc in the search function.

Browse to "Local Policies" -> "Security Options". Now look for the entry "Network Security: LAN Manager authentication level" and open it. Click on the dropdown menu and select "Send LM & NTLM - use NTLMv2 session security if negotiated". Apply the settings.

In the Advanced sharing settings page of Network and sharing center, you need to have it set as Work/Home profile. Try

-Enable network discovery
-Turn on file and print sharing
-Turn off password protected sharing
-Use user accounts and passwords to connect to other computers

The other settings such as encryption I have set as use 128 bit encryption.

Please check related policies.

1. Enter “gpedit.msc” in the Start Search box.
2. Open “Computer Configuration”/Windows Settings/Security Settings/Local Policies/Security Settings.
3. In the right pane, enable the following policies:

Network access: Allow anonymous SID/name translation
Network access: Let Everyone permissions apply to anonymous users

Also please disable the following policies.

Network access: Restrict anonymous access to Named Pipes and Shares
Network access: Do not allow anonymous enumeration of SAM accounts
Network access: Do not allow anonymous enumeration of SAM accounts and shares

Now, go into the control panel and search for homegroup. Click "Choose homegroup and sharing options" and remove yourself from any groups.

Reboot both machines.

Now, when you attempt to access a admin share, you should get a login box. Enter a username and password of an account present on the other machine, and you should get in.

Worth noting: if you attempt to browse to a share like \\workstation\share and double click on it, you may just get access denied. This is because Windows 7 is trying to use its local credentials to log into the share and failing. If you then attempt to log into an admin share, you will get a different error about connecting to one resource with more than one name.

Open a command prompt and type net use * /delete to remove all network connection sessions that are cached... then try to open the admin share by going to \\workstation\c$. It will ask you for a username and password, and that should work.

You can also create a mapped drive, and check the box telling Windows 7 you want to use different credentials. When you create the drive, it will ask for a username and password. Check the box to remember the password, then enter the local user name of an account on the machine which is sharing the folder you want to access (no domain or computer name in front of it... just username). Voila!

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!