JasonSamuel.com

Yes, you can get Exchange 2003 ESM tools working with both Windows 7 x64 and x86 OSes! Microsoft does not seem to want to support Windows 7 and Exchange 2003 system management tools. They have not released ESM for Windows 7 so you have to work around it. Many companies out there are still using Exchange 2003 so I’m not sure why they don’t allow for backwards compatibility.

To get ESM for Exchange 2003 to work on BOTH Windows 7 32 bit and 64 bit OS flavors, perform the following:

1. Download and install RSAT Tools for Windows 7 (Remote Server Admin Tools) here, select x86 (x86fre_GRMRSAT_MSU.msu) or x64 (amd64fre_GRMRSATX_MSU.msu) depending on what flavor of Windows 7 you are using – http://www.microsoft.com/downloads/en/details.aspx?FamilyID=7d2f6ad7-656b-4313-a005-4e344e43997d&displaylang=en

2. Download Exchange System Manager for Windows Vista here (ESMVISTA.EXE) but don’t install it yet (see step 3) – http://www.microsoft.com/downloads/en/details.aspx?familyid=3403d74e-8942-421b-8738-b3664559e46f&displaylang=en

3. Do a silent install of ESM. This circumvents the OS check and allows you to install ESM for Vista on Windows 7. You can do this by opening a command prompt and typing this in the directory you downloaded ESMVISTA.MSI to:

ESMVISTA.MSI /q

4. If you are using Windows 7 x86, you are done and you can open up Active Directory Users and Computers (ADUC) and you will see the Exchange tabs for your users.

5. For Windows 7 x64, it’s a little tricky. It just won’t display Exchange tabs in ADUC when you open it. It took my some trial and error for a few hours before I figured it out. You have to run an MMC snapin in 32 bit mode to get the tabs to work. You can do this by opening a run prompt and typing:

mmc /32

then adding the “Active Directory Users and Computers” snap-in (should be the 3rd option). I am thinking this is because the ESM for Vista package was not designed for x64 and some level of compatibility is missing. Evidence for this is that if you check the target for the ESM or ADUC shortcuts, you will see this which clearly shows it’s installed in the x86 Program Files folder:

C:\Program Files (x86)\Exchsrvr\bin\exchange system manager.msc
C:\Program Files (x86)\Exchsrvr\bin\users and computers.msc

Now the problem is that everytime I added the ADUC snapin in an MMC window, the text for it would disappear and I would get an error saying “MMC cannot initialize the snap-in” followed by the MMC crashing. I checked the application event log and found the following:

Faulting application name: mmc.exe, version: 6.1.7600.16385, time stamp: 0x4a5bc3f1
Faulting module name: ntdll.dll, version: 6.1.7600.16559, time stamp: 0x4ba9b29c
Exception code: 0xc0150010
Fault offset: 0x0008454b
Faulting process id: 0x98c
Faulting application start time: 0x01cb970a650fbae3
Faulting application path: C:\Windows\SysWOW64\mmc.exe
Faulting module path: C:\Windows\SysWOW64\ntdll.dll
Report Id: aac5fead-02fd-11e0-9946-005056b64915

So obviously a core Windows 7 x64 system file is the culprit, ntdll.dll. Luckily, there is a release candidate for Windows 7 SP1 available for download here (windows6.1-KB976932-X64.exe):

http://www.microsoft.com/downloads/en/details.aspx?FamilyID=c3202ce6-4056-4059-8a1b-3a9b77cdfdda

I assumed that the service pack might fix whatever the issue was with ntdll.dll since it is a core system file. Turns out I was right, after installing Windows 7 SP1, I can now successfully open an MMC window in 32 bit mode and add the ADUC snapin. Now all my Exchange tabs show up in ADUC (Exchange General, E-mail Addresses, Exchange Features, & Exchange Advanced). See screenshot below:

Now I’m not advising you deploy a release candidate service pack into your environment. But for systems admins, we typically have a bit more leeway on our systems than end users so if you are under no policy restricting installing a release candidate on your workstation, then go for it. You can even install it in a VM temporarily until SP1 is released so you don’t have to jeopardize your workstation with an RC build. Let me know how it works out for you!

I’m not an Altiris expert by any means but I did help troubleshoot a new install of Altiris ServiceDesk 7 on a Windows 2003 x64 server running IIS 6 today. Basically every time you clicked on the Altiris Process Manager icon on the desktop, it would give you an XML error.

The XML page cannot be displayed
Cannot view XML input using XSL style sheet.  Please correc the error and then click the Refresh button, or try again later.
A name was started with an invalid character.  Error processing resource http://localhost/ProcessManager/. Line 1, blah blah blah

I skimmed over the requirements section in the ServiceDesk deployment guide and it did not state if IIS needed to be in 32 bit mode or 64 bit mode. I assumed 32 bit mode would be fine and did the following to resolve the issue. If you want to run it in 64 bit mode (assuming Service Desk 7 will run in 64 bit mode), you just need to leave IIS running in 64 bit mode. I did not try it so let me know if it works for you.

Now on to the instructions for running Altiris Service Desk in 32 bit mode:

1. Install .NET 3.5 SP1 using the dotnetfx35.exe installer. It is a 197 MB file and can be downloaded here:

http://www.microsoft.com/downloads/en/details.aspx?FamilyID=d0e5dea7-ac26-4ad7-b68c-fe5076bba986&displaylang=en

2. Install IIS normally.

3. Since you are installing Service Desk 7 on a Windows 2003 x64 server, I figured I would make IIS run in 32 bit mode instead of 64 bit mode. Go to a command prompt and type:

cscript %SYSTEMDRIVE%\inetpub\adminscripts\adsutil.vbs SET W3SVC/AppPools/Enable32bitAppOnWin64 1

**** If you want to try running it in 64 bit mode, give this a shot instead of the above. I have no idea if it will work or not since I didn’t try it:

cscript %SYSTEMDRIVE%\inetpub\adminscripts\adsutil.vbs SET W3SVC/AppPools/Enable32bitAppOnWin64 0

4. Open IIS Manager and expand the “Web Service Extensions” folder. See if ASP.NET v2.0.50727 (32-bit) is in there. If it is, click on it and set it to Allow. If it is not there, go to:

C:\WINDOWS\microsoft.net\Framework\v2.0.50727\

In command prompt and then type:

aspnet_regiis.exe –i

which will register ASP.NET with IIS. Now go back to IIS Manager > Web Service Extensions and refresh. You should see it in there now. Set it to Allow.

5. Now click on the Altiris Process Manager icon on your desktop. The website should display now. Double check the application event log for any .NET related errors if it doesn’t come up. You should see the below if all goes well:

Always remember to sysprep when cloning a node! MSMQ (Microsoft Message Queuing) uses a registry valued called QMId located at:

HKLM\Software\Microsoft\MSMQ\Parameters\Machine Cache

which has to be unique on all your servers or it will cause all sorts of issues. Sysprepping a server generates a new SID which also generates a new QMId in the process. If you don’t do this and have multiple servers out there with the same QMId, you will see strange things like messages remaining in the outgoing queue in limbo and sometimes just disappear completely with no trace in journaling anywhere. Bottom line, don’t confuse MSMQ! It’s fragile!

Thankfully John Breakwell (MSMQ guru at Microsoft) blogged about this exact issue which made me realize what was going on in the environment I was troubleshooting. Well done John!

http://blogs.msdn.com/b/johnbreakwell/archive/2007/02/06/msmq-prefers-to-be-unique.aspx

I simply ran sysprep and resealed the clone to fix it. It automatically generated a new QMId in the process so I didn’t have to follow the exact steps John had blogged about. It was a simple mistake which can be avoided in the future by using the Guest Customization Wizard in VC to automatically sysprep when creating the clone.

BTW, you can check if your SIDs are identical on a server by using getsid.exe. Download the Windows XP Service Pack 2 Support Tools:

http://www.microsoft.com/downloads/details.aspx?FamilyId=49AE8576-9BB9-4126-9761-BA8011FABF38&displaylang=en

and use the getsid.exe tool to compare SIDs on your Windows servers. Usage syntax is here:

http://technet.microsoft.com/en-us/library/cc784314%28WS.10%29.aspx

Since I’m blogging about MSMQ, let me take a moment to plug QueueExplorer (http://www.cogin.com/mq). This is hands down the best MSMQ management software I have ever used and the developer is very open to feature requests. Give them some business and tell them Jason sent ya! Check out a screenshot of it below:

IP Address conflict? Have you narrowed the MAC down to being a VM in one of your ESX/vSphere clusters? Well use vSphere PowerCLI to figure out what device and adapter is causing the conflict.

Example, if your MAC is 005056b60b13:

Get-vm | Select Name, @{N="Network";E={$_ | Get-networkAdapter | ? {$_.macaddress -eq "00:50:56:b6:0b:13"}}} |Where {$_.Network-ne ""}

And it will output the VM name and the Network Adapter causing the conflict.

Disasters happen and with a bit of skill and some luck, you might be able to get back into your operating system.  But you might notice a bunch of things out of place or missing if you had to do a Windows repair or use the Recovery Console to set things back to factory settings.

One of the tools I like to use is System File Checker (sfc.exe) which compares your file system against the original install disk and replaces missing or corrupt system files as needed.  Just go to a command prompt and type:

sfc /scannow

and Windows File Protection will begin scanning all your protected system files immediately.  If you get a prompt asking you to insert a disk, just cancel out and edit your registry key here:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup

and verify SourcePath is set to your CD-ROM drive with your install CD in it.  You’ll have to reboot to make sure the changes take effect.  Also you might want to verify:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup\ServicePackSourcePath

is set to C:\WINDOWS\ServicePackFiles just so your service packs you have installed after installing the original OS are taken into account and not overwritten by older versions.

You can use OpenSSL and run this command:

openssl.exe s_client -connect www.mysite.com:443

which will use a generic SSL/TLS client to connect to your site and give you a ton of diagnostic info.  You can see your entire SSL cert chain, the SSL handshake, SSL session info, etc.  Here’s a full list of switches you can use with it:  http://www.openssl.org/docs/apps/s_client.html

And here’s a great online tool to graphically verify your SSL chain is intact:  http://www.sslshopper.com/ssl-checker.html

By default, most applications write events to the Application Event Log.  This is a great central place to write logs to but sometimes you might have a requirement to log informational events from an application and you don’t want it filling up your Application Event Log because of the sheer number of informational events you might get a short period of time.  The solution is to create a custom event log for your application to hold these events.  You can then set max log size, overwrite rules, filters, etc. on this event log while your Application Event Log remains clean and intact.

The first step is to create the new log.  You have to do this in the registry.  Open up regedit and navigate to:

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Eventlog

Right click on the Eventlog key and click New > Key

Name this new key the same name you want your new event log to be named.  By default it will create the new .evt file here:

C:\WINDOWS\System32\Config\New Key #1.evt

You can always rename it by editing the string value data in the registry if you like.

Now you need to add Sources to your new event log.  Right click in the right window pane under your new key and add a new Multi-String value called “Sources” and add the name of each of your applications on each line.  It should look something like this:

Now you need to move the association of your application from the Application event log to your new Custom log.  Just expand the “Application” key located at:

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Eventlog\Application

and copy whatever key you see in there for your app under your new Custom log:

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Eventlog\CustomLog

There’s no copy/paste command so you can recreate the key if it’s small or you can export/import if it’s something complicated and you are afraid of mistyping something.  MAKE SURE to delete it from Application after you add it to the Custom log or it will not write events to your new log since Windows thinks its still associated with the Application log.  If it is a custom source, you need to create a DWORD value under this key with the value of 1:

You will also notice my custom app in this example is a .NET 2.0 appliaction so I want .NET to write the events to the log.  I have to create a string value called EventMessageFile and give it the path to the .NET 2.0 event log message dll:

C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\EventLogMessages.dll

Now you should reboot your server.  When it’s back up, check and see if your new event log appears under Event Viewer.  If your application is not writing events to your new log, test it manually by opening a command prompt and going to:

C:\WINDOWS\system32

and typing:

eventcreate /l CustomLog /t Information /so Application1 /id 1 /d "Test message"

You should get a message saying it was successfully written or you should get an error message with details on why it was not written.  If you followed the steps in this blog post, it should write the event just fine.

If you’ve ever used Urchin 6 for web analytics (Google’s pay for version of Google Analytics aimed at enterprises), you have probably seen profiles stuck in a “Running” state.  If you hit Run Now, you get this error message:

12008 – Action: Failed to cancel urchin process.

If you try to reschedule the profile, you get this error message:

12007 – Action: Failed to add profile to the scheduler queue. The profile is already in the queue.

This happens because Urchin’s scheduler is very sensitive to server reboots.  If you have jobs scheduled to run at night and let’s say you push patches to the server and reboot in the middle of the night, it can cause this error to appear on some of your profiles.  You get these errors because the log processing engine and scheduler never received the proper exit signals which means there will be database entries in the MySQL database that will be in an inconsistent state.  When the server boots back up, the log processing engine cannot pick back up where it stopped and the web GUI will show the profile is “Running” even though it is not.

The quick solution for this is to navigate to your Urchin bin folder via command prompt.  Here is an example path:

C:\Program Files\Urchin6\bin

then type:

urchinctl stop

which will stop all Urchin processes.  Then open up MySQL Command Line Client and type:

use urchin;
delete from uprofiles_queue;

This switches the database to the urchin database and deletes all running profiles.  Now if you go to to the web GUI under Profile Task Scheduler, you will see everything looks normal.  Now trying running the job again and it should work.  You should get a message saying:

12009 – Action: Profile has been queued to run. Please check the Profile Task History screen for status and runtime output.

Now don’t forget to restart your Master and Slave scheduler services or the job will remain in a queued state until they are back up:

urchinctl start

Now verify the job is actually running properly by clicking the green “Running” link for the job and you should see it processing the logs.

.NET 2.0 counters won’t show up in perfmon by default when using the /wmi switch.  They will show up in you just use regular perfmon but if you are trying to monitor .NET 2.0 counters via WMI, you are stuck.  Microsoft is aware of this and released 951683 to fix this issue.  You can request the hotfix from CSS here:

http://support.microsoft.com/kb/951683

This hotfix is included with .NET 3.5 SP1 onward so if you have it installed, you shouldn’t experience this issue.  After installing the hotfix (does not require a reboot), just restart the WMI service and run this from command line:

winmgmt /resyncperf

which will resync counters with WMI.  Then open perfmon using “perfmon /wmi”  and you will see the missing counters. 

You can also use the wbemtest.exe utility to test and troubleshoot WMI related issues.  Just run this from command line:

wbemtest.exe

Click the Connect button and change the very first field to “root\cimv2″.  Then press Connect and then click Enum Classes on the next window.  Leave the superclass blank but change it to Recursive and press OK.  It will query every WMI class on the server and you can click on them to get further details.  This should help you tremendously if you write your own WQL queries!

You can install pretty much any windows component locally or remotely on a server.  Here is an example of installing SNMP using an answer file via command line locally on a server:

sysocmgr /i:%windir%\inf\sysoc.inf /u:”\\server\share\snmp.txt” /q

This will install SNMP quietly using the answer file I give it which is located on a file share.  Here are the contents of the answer file:

[NetOptionalComponents]
SNMP = 1

[SNMP]

Send_Authentication = Yes
Accept_CommunityName = mine_ro:Read_Only
Any_Host = No
Limit_Host = xxx.xxx.xxx.xxx

This will automatically configure a new read only community you specify and add a single host that is allowed to connect (you can add more IPs but adding a comma after each one).  The only dilemma is that during the install, it needs to get at the i386 directory and by default in the registry, it is pointed to “D:/i386” more than likely since that is typically the CD-ROM drive you installed the OS from.  We just need to run a quick registry update to two keys that point it to the C: drive before running the line above and it should work with no issue.  This can be done in bulk on servers too using whatever remote management tool you prefer:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\ CurrentVersion\Sourcepath

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows \CurrentVersion\Setup\Sourcepath

Keep in mind sysocmgr.exe has been replaced in Server 2008 by ocsetup.exe.  You can read up on command line switches for it here:

http://technet.microsoft.com/en-us/magazine/dd673656.aspx
http://technet.microsoft.com/en-us/library/cc766272(WS.10).aspx