Renew or replace ISA 2006 SSL certificate for CSS in workgroup

Even though ISA 2006 feels old these days, there are still a lot of people running it.  It works, it is stable, and it typically cost money to go to the latest version (TMG or UAG).  Every so often, I run across ISA arrays in a workgroup.  The configuration is slightly different than a domain-based ISA array and requires a little bit more maintenance.

One common issue is renewing (typically replacing) the SSL certificate that the CSS uses in workgroup mode.  The process isn't as straight forward as it should be and I've run into customers that don't even realize that there is an SSL certificate for the CSS (until ISA stops accepting configuration changes or other issues crop up). 

Richard Hicks has a an overview of the process which got me thinking about putting a bit more detail out there (much of this information is available elsewhere, but typically spread across multiple sites). 

First, see Richard's post:
http://tmgblog.richardhicks.com/2009/03/05/isa-server-2006-workgroup-deployment-certificate-renewal/

I added a few comments (awaiting moderation as of right now) earlier this evening.  Basically, a few details that you might find handy:

1.  A lot of people struggle with obtaining the .PFX file.  GoDaddy and others typically offer .CRT files.  You need to complete the SSL install on the original IIS server which will install the certificate (with private key) on the server, then export it from the Certificates MMC (and during the export, you can choose to include the private key which will get you the required .PFX file).

2.  ISACertTool isn't really installed.  It is extracted.  And it is best to extract it to the program directory where ISA is installed (default is C:\Program Files\Microsoft ISA Server).  Otherwise, the tool will complain about a missing .DLL.

3.  To simplify the procedure, copy your .PFX file to the same directory (C:\Program Files\Microsoft ISA Server).  Then, you won't have to specify a path when you use the /st switch.

4.  If you are using a public CA (as is typical with ISA implementations), you won't need to worry about the root CA certificate in most cases (as those will be there by default with  your Windows operating system installation).  Some might argue that you can use an internal certificate (or generate one from an internal CA) but at $17.95 a year, there are benefits to the public CA (centralized management of all ISA certificates, not just external certificates is one example).  I typically opt for the public CA.

Finally... it is important to test and verify... BUT... if your old cert isn't expired, how do you verify now?  The best way I've found is to launch the Certificates MMC, specify the local computer (ISA CSS), then specify a service account (which should be ISASTGCTRL).  The old and new certificate should be listed there (which indicates a successful installation.  Of course, the ISACertTool should give you a success message too.  Then, add a reminder to your calendar for the day after the old cert expires - you can run through additional testing and clean up the old cert (delete from Certificates, etc.).

Restart in a long long time (funny dialog message)

Might as well post this one too.  After pushing out some updates to a client machine, I got the common restart dialog but this one had a funny sense of time:

Funny Microsoft error message

I was creating a trust recently and came across a funny error:

OCS 2007 R2 - server issues - limited calling

So I ran into a small issue with an OCS environment recently.  All of the MOC clients were showing a small red exclamation point in the tray icon with a message indicating server issues and limited calling.  Combined with that, 4 of the OCS services were stopped and wouldn't start.  The 4 services were:  Office Communications Server Conferencing Announcement, Office Communications Server Conference Attendant, Office Communications Server Outside Voice Control, and Office Communications Server Response Group.  Some Google searching revealed a lot of people running into similar issues (but with different symptoms or slightly different error messages).  I was finally able to narrow down the fix when I ran into Event ID 33020 stating that the CAA's private contact object is missing.

The fix?  Deactivate all 4 applications in OCS and reactivate (using the same information that they were originally activated with).  This is a very quick and easy process.  Then, start the 4 services.  Thereafter, users had to log out out OCS and log back in and the red exclamation point was gone and full functionality resumed.

How to determine a VM's management operating system (Hyper-V)?

I recently came across a VM while generating a server list.  I have a script that queries Active Directory for all server-based operating systems.  I take that script and query the servers for the make/model info.  Recently, I saw a VM in the list and was curious because I wasn't familiar with it.  My script uses WMI to query two items:

SystemManufacturer
SystemProductName (AKA Model)
 
For Hyper-V VM's, the SystemManufacturer is Microsoft Corporation.
For Hyper-V VM's, the SystemProductName is Virtual Machine.
 
There are a number of ways to get the values.  WMI using VBScript.  PowerShell.  Or just reading the values from the registry via REGEDIT.
 
REGEDIT:  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SystemInformation
 
PowerShell:  Get-WmiObject -Query "select * from Win32_ComputerSystem"
 
VBScript (watch out for line wrapping, tie this VBScript into larger script):
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\CIMV2")

Set colItems = objWMIService.ExecQuery("SELECT * FROM Win32_ComputerSystem", "WQL", wbemFlagReturnImmediately + wbemFlagForwardOnly)
For Each objItem In colItems
objTextFile.WriteLine strComputer
objTextFile.WriteLine objItem.Manufacturer & " " & objItem.Model
objTextFile.WriteLine
Next

If anybody wants the entire script (for automating querying a large number of servers), comment and I'll post it.

However, as others have pointed out (see:  http://www.commandbreak.com/CommentView,guid,53004814-7f71-4772-bba2-4b77988d9b73.aspx#commentstart) - other Microsoft virutalization platforms return that same data.  So you have to look a little further to distinguish Hyper-V VM's:
 
BIOSReleaseDate
 
Generally speaking, the BIOSReleaseDate for Hyper-V VM's will be 2008 and later while everything else will be older (2006, etc.).  This isn't that concrete but it's a starting point.  But now what?  Even if you determine that you have a Hyper-V VM, how do you determine which Hyper-V host it resides on?  Where is the management operating system?
 
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Virtual Machine\Guest\Parameters
 
There are three values here that are of interest:
 
HostName REG_SZ

PhysicalHostName REG_SZ
PhysicalHostNameFullyQualified

Here is where I finally found the concrete answer.  Once you have the host name, you can quickly manage it and get the rest of the details you need.  I haven't had a chance to compare this data with that of Virtual Server.  But I think I'll build some of this data into my scripts.

For those asking for the same thing but for VMWare (ESX or VSphere) - I cross checked this against both and while the make/model info is valid, the rest isn't.  I will have to dive into determine your host ESX/VSphere server from a VMWare VM another time.

Purchased a Christmas gift online at Bloomingdale's on 12/11/09. Spam from Bloomingdale's began on 12/12/09 (efficient, eh?). In the month since, I've received 24 pieces of junk mail from them. Just unsubscribed (although never subscribed to begin with).

FAT vs. NTFS for USB drives

I was going to buy a new USB drive for my keychain the other day. I had a couple of gift cards from Christmas and figured it was time to upgrade my 16GB drive. Just before I was about to click the buy button, I realized that I needed to clarify a couple of things first. For me, it was specifically related to being able to copy files larger than 4GB to the drive. By default, keychain drives are formatted with FAT32 and the maximum file size for a FAT32 formatted drive is 4GB (to be technical, just under 4GB). Like many others, I use my keychain drive as a utility drive - temporarily storing large .ISO files (among other things). And these .ISO files can get larger than 4GB.

I had heard some negative things about using NTFS for USB keychain drives. To see the latest thoughts, I searched Google and read a few of the forums and blogs. And the information is still negative. And many times, wrong. Some of the common things reported about NTFS on USB keychain drive: slower performance, inability to access files on other machines without clunky workarounds, file corruption if you don't properly eject, and the inability to disable write caching on NTFS formatted USB keychain drives. Now if all of these things were true, I'd be stuck using FAT32!

I decided to put some things to the test. Obviously, I am not a scientist and the sampling is incredibly small. But useful nevertheless.

Computer: Dell E4300, P9400, 2.4GHz, 4GB of RAM, Windows 7 Pro (64-bit)
USB keychain drive: Corsair Flash Voyager 16GB (about 2 1/2 years old)

I started by enabling write caching on the Corsair (via Device Manager in Windows). This allowed me to format the Corsair with NTFS. I formatted the Corsair with NTFS and left write caching enabled. I proceeded to copy a 3.31GB .ISO file from my laptop to the Corsair. Then I deleted the file, disabled write caching, and copied the file again. Finally, I formatted the Corsair with FAT32 and copied the file a third time. I performed the same steps for a 1.14GB .ISO file as well. The following table shows the results of the copy operations.

Operation	File System	Elapsed Time
3.31GB file copy	NTFS w/ caching	6 min. and 18 seconds
3.31GB file copy	NTFS w/o caching	6 min. and 14 seconds
3.31GB file copy	FAT32 w/o caching	6 min. and 25 seconds
1.14GB file copy	NTFS w/ caching	2 min. and 13 seconds
1.14GB file copy	NTFS w/o caching	2 min. and 12 seconds
1.14GB file copy	FAT32 w/o caching	2 min. and 15 seconds

First things first, performance is very similar. Certainly not a noticeable difference. In my case, my entire usage of the keychain drive is to copy files to it for temporary storage, then copy them off at some point thereafter. I'm not using it for online editing of files. I'm not using it for ReadyBoost. I'm just using it for temporary, portable file storage. Based on my tests, I have nothing to worry about with NTFS and performance. In fact, I may gain a slight edge (my calculation shows approximately 1.65% better performance under NTFS w/o caching)!

What about the ability to access your files from other machines? That seems to be something people are worried about too. And if you believe what you read, you won't be able to access your files! Access denied! NTFS permissions will get in the way, you'll have to take ownership, assign permissions, etc. What people forgot to look at was the default permissions. The default permissions on a freshly formatted drive? Everyone, Full Control. What does that mean? That means anybody and everybody can access the files, create files, delete files, etc. In other words, the permissions are compatible with any Windows machine! Just to be sure, I took my freshly formatted USB keychain drive (NTFS w/o caching) to a friend's machine, stuck my keychain drive in, and tested. I was able to access everything and copy new files to the drive. I took it back to my original test machine and was able to access everything (including the new files). Worked flawlessly.

OK... so what about file corruption and proper ejections? Don't you have to eject once you format to NTFS? Well, only if you keep write caching enabled. And I'd recommend disabling write caching. You don't want to have to tell anybody you hand your keychain drive about proper ejection. And you'll want to just rip the keychain drive out of the USB slot on demand. So disable write caching. So isn't NTFS a journaling file system? Yes. Which means that sometimes a write isn't really a write. Sometimes, a write stays in memory before being written to disk. Could that cause an issue? Not for my use. I'm going to copy a few .ISO files to the drive and take it out thereafter. In my limited testing, I have been unable to corrupt and files or lose any data.

Tests performed:
Edit text file, click Save, and immediately pull keychain drive out
Edit text file with 88KB of new data, click Save, and immediately pull keychain drive out
Edit text file with 1 line of new data, pull keychain drive out before saving, then put keychain drive back in, click Save

All tests were successful. No complaints from Windows. No loss of data. No corruption. I've heard of some elaborate things that will cause corruption but they aren't real world situations. One example was to hibernate your laptop with your keychain drive in, pull the keychain drive out, insert it to another machine, copy new data to it, then resume your laptop from hibernation and put the keychain drive back in. This created a problem under specific versions of Windows. But for me, that's not very convincing. It isn't real world use and certainly isn't my use.

Finally, I'll address the ability to disable write caching on NTFS formatted USB drives. Yes, you can disable write caching. No issues there. And by doing this, it allows for the quick removal of the drive (just like you can with the default FAT32 formatted drives).

Although limited testing, I think there's enough good here to warrant a serious consideration for NTFS formatted USB keychain drives. And that's STRICTLY for the ability to work with files larger than 4GB. I didn't even get into the other benefits of NTFS (compression, security, encryption, file system recovery, etc.). Some of you may ask, doesn't NTFS wear out the USB keychain drives? Lots of stories on the web about this. Well, much of that information is old. New methods are in use now and components have improved greatly. This question is best answered by quoting Corsair's life span FAQ:

"Will my Corsair USB Flash drive last more than 10 years?
Yes. All Corsair flash drives are built with memory components that can handle AT LEAST 10,000 write cycles; typically they will handle an order of magnitude more than this. So, this means that in order to exhaust the drive in ten years, one would have to write to EVERY BLOCK in the device about 2.7 times per day, every single day. We simply can’t conceive of such a usage scenario; this would mean that on a fairly typical 8 GByte drive, one would need to write over 21 GBytes of data to it every day for ten years! USB flash drives simply are not used in this way.
If one thinks he or she might actually try this, we suggest buying a Corsair Flash Voyager GT or a Corsair Flash Survivor GT USB drive. They are built with components guaranteed for 100,000 write cycles. With these, one can write over 210GBytes of data to the drive each day, for ten years!"

Corsair's Wear Leveling and Life Span

What's next? Start testing yourself and see if you agree!