Unity Migration Blog

I have confirmation from Bill C (he checked with Microsoft) that the Windows Server license covers both the 32 bit and 64 bit versions. Given that we're licensed, I think we should move to 64-bit rather than continuing to install 32-bit Windows, unless there is a compelling reason not to...

In working on improving the Plug and Play detection in WolfPrep so that it can properly identify more sound cards, I came accross PnP-X: Plug and Play Extensions for Windows

I'd love to report that based on the information inside, WolfPrep would handle PnP better, and use all the freshest Vista technologies.

Alas! I can't even read this document with the intent to implement anything in it! From the abstract page:

LICENSE NOTICE. Access to and viewing and implementation of the technology described in this document is granted under the Microsoft Windows Rally Program License Agreement (“License Agreement”). If you want a license from Microsoft to access, view or implement one or more Licensed Technologies, you must complete the designated information in the License Agreement and return a signed copy to Microsoft. The License Agreement is provided at the end of this document. If the License Agreement is not available with this document, you can download a copy from the Windows Rally Web site at http://www.microsoft.com/rally.

I really hate to flame Microsoft unnecessarily, but for heavens sake people! A *secret* and privately licensed PnP specification? I was hoping to use this information to make installing Windows systems easier on this campus.

For the record, I have not read the document, 'cause if I can't use the information inside it's simply a waste of time. We'll struggle along without whatever benefits PnP-X may or may not offer.

I hope anyone involved with hardware development will resist this nonsense, and that all customers will react with the same contempt that I have for this practice.

I've added some monitoring to the LICENSE00 server, which host the KMS licenses for Windows Vista Clients, and the Autocad FlexLM license manager.

In addition to the usual Nagios service checks for Windows Server, there is a small script on the SCRIPTS00 server which runs once a day to generate a status web page. While generating this page, it submits a passive check to the campus Nagios server so that our main monitoring tool can reflect our actual status.

There is also a flexLM license checking plugin that will periodically check the AutoCAD licenses, and give us an alert whenever we max out. I don't have this installed just yet, but when it's installed, it should give us a much better level of monitoring!

Well, with NetBIOS off at least a few hosts, my WMI scripting is begining to work. :-)

We have a new page to track the number of KMS activations for Windows Vista are on our server(s). You'll find it at http://microsys.unity.ncsu.edu/status/KMS-Licenses.html

I intend to repackage this as a nagios plugin that will report "warning" should the actual license count get close to the minimum count, and "critial" should the minimum not be met. This would allow us to get proactive warnings from Sysnews, when combined with proper testing intervals and notifcation rules.

There are still some things to be sorted out before making any sort of official announcement, but work is progressing towards getting campus wide network booting a reality.

As it stands, we have two servers installed, on in HLB and one in DC2. There are not yet load balanced and syncronized, but that's more an issue of staff time then of relative difficulty. :-)

We have both Wolfprep Windows XP installations, and Realm Linux installations available. I have loaded the Windows Deployment Services binaries up to the server, but as of this moment we don't yet have a functional WDS example.

We have two diagnostic/utility applications available also. Enter "memtest86" from the pxe boot menu to run memory diagnostics, or "delldiags" to run the Dell 32bit graphical diagnostics.

To test any of this stuff, you must set your DHCP template in QIP to "PXE-All" It's unclear to me if this will work on all subnets on campus, but it will by fall. :-)

We plan to support Intel Macintoshes as well, but have not yet built an OS X installation.

When we get WDS, OSX and the replicated servers going, we'll have a big announcement, as we think this is going to have a postive impact on the campus Disaster Recovery stance. Having a central and universal means to deploy workstations will reduce the madness following a disaster to locate both installation media and licensing codes. The tftp servers are configured to be usuable in a "stand-alone" mode should the rest of the infrastructed be unavailable, and have the software pre-installed to offer services like DHCP/PXE should there be a period where QIP based PXE had not yet been restored to service during a crisis.

The renewal interval for the KMS service has been increased to 30 days -- the maximum allowable value. The default is 7 days. This is the command that was entered to change the value:

cscript slmgr.vbs -sli 43200

LICENSE00 was then rebooted.

The number of activations the KMS service manages must be kept above 25, also known as the "n-count". Clients periodically try to check in with the KMS service per the renewal interval to refresh their activations. The KMS service also knows that the clients should try to check in. If the KMS service does not hear from the client for a duration longer than the renewal interval, it decreases its n-count. Our n-count decreased because we installed Vista over and over again on the same machines to get the count above 25.

This should help us keep the n-count above 25 until enough Vista clients actively use the KMS service.

The unity.ncsu.edu and unity.ad.ncsu.edu DNS domains have been updated by Comtech so that the KMS SRV records are configured per our documentation. They are configured to use the kms1 and kms2 CNAMEs.

C:\>nslookup -type=srv _vlmcs._tcp.unity.ncsu.edu
Server: ns3.ncsu.edu
Address: 152.1.1.206

_vlmcs._tcp.unity.ncsu.edu SRV service location:
priority = 0
weight = 100
port = 1688
svr hostname = kms2.unity.ad.ncsu.edu
_vlmcs._tcp.unity.ncsu.edu SRV service location:
priority = 0
weight = 100
port = 1688
svr hostname = kms1.unity.ad.ncsu.edu

C:\>nslookup -type=srv _vlmcs._tcp.unity.ad.ncsu.edu
Server: ns3.ncsu.edu
Address: 152.1.1.206

_vlmcs._tcp.unity.ad.ncsu.edu SRV service location:
priority = 0
weight = 100
port = 1688
svr hostname = kms2.unity.ad.ncsu.edu
_vlmcs._tcp.unity.ad.ncsu.edu SRV service location:
priority = 0
weight = 100
port = 1688
svr hostname = kms1.unity.ad.ncsu.edu

I installed Vista after the change was made and it was activated using kms1.

I also created the kms.unity.ad.ncsu.edu CNAME to be used for manual activations. We will have to set it up for round-robin once the 2nd license server is online.

We have begun some documentation regarding our KMS services and other volume license activation issues:

http://microsys.unity.ncsu.edu/documentation/Microsoft-Volume-License-Activation/

Please check it out and let me know if anything should be added or changed.

Also, I registered the cnames kms1.unity.ad.ncsu.edu and kms2.unity.ad.ncsu.edu. These currently point to license00. We should instruct people to use these rather than the actual server names. When a second license server is added, all we'll need to do is change what kms2 points to.