Unity Migration Blog

I'm trying to find out if Client-32 can interoperate with AD under _any_ conditions.

I've installed a clean windows machine on a VM, joined it to the domain, and then installed Client-32 v4.91SP4 plus the "491psp4_lgncxw32" patch to fix "contextless login prolems with Citrix" Under "advanced properties" I've unchecked "Initial Novell Login" so nwgina doesn't nuke msgina.dll.

Contextless login with LDAP is all configured.

Whrn "Login Without Novell's GINA" was "On" I didn't get either a dialog or a login when I authenticated as a domain user. I set it to "Off"
and still got no Novell login.

Tomorrow I'll try installing the optional "Identity Manager" C32 bits, and see if that helps.

This month's issue of TechNet Magazine has a nice article giving an overview of the capabilities of Microsoft's OS deployment tools. The article is entitled "Deploying Windows Vista with BDD 2007" but the same methods can also be used to deploy Windows XP. The article describes the automated processes and tools Microsoft supplies to create images, customize images, manage drivers, apply updates, etc. I gave a "dog and pony" presentation covering the same material at one of our Microsys planning meetings a while ago but this article does a better job.

These features are being used to deploy our pilot environment. These features were also used to easily create an unattended Vista installation image which is used to reinstall Vista over and over again to keep the KMS count up.

The components described in the article are installed and operational on WDS00 if you want to take a look.

Here's the link:
http://www.microsoft.com/technet/technetmag/issues/2007/09/BDD/default.aspx

Well, I was hoping to be able to include Novell's Zen 7 SP 1 Hot Patch 6 in the Fall WolfPrep CD-ROM, but alas! It has defeated me.

Released on the 31st of July, I had hoped that it would be 'fresh' enough to boot Dell 745 workstations with their SATA controllers in pure SATA mode.

I'll have a patched version of the existing CD-ROM, configured to read from the new Wolfprep volume on the Zen imaging server, but it won't have any of the zippy new features I was hoping to add.

Using mod_auth_sspi, WEB00 was configured with to serve the new pilot workstation installaion ISO file to certain authenticated users.

The ISO download page is HERE. The download page doesn't require authentication. The URL where the ISO file resides does. It is located HERE.

The ISO file actually resides on WDS00. I created an alias directly to this location rather than copying the ISO somewhere else because the ISO is generated automatically in this location. I will eventually link this into DFS.

The Apache conf file is called download-install-sspi.conf and resides in the conf.d directory on WEB00. This is what it looks like (Note: the greater than and less than signs were removed because the blog wouldn't allow them):

Alias /download/installation "//wds00.unity.ad.ncsu.edu/distribution$/boot"

IfModule !mod_auth_sspi.c
LoadModule sspi_auth_module modules/mod_auth_sspi.so
/IfModule

# Use SSL
RewriteEngine On
RewriteCond %{SERVER_PORT} !^443$
RewriteRule ^/download/installation/(.*) https://microsys.unity.ncsu.edu/download/installation/$1 [L,R]

IfModule mod_auth_sspi.c
Location /download/installation/
AuthName "the Unity Active Directory domain"
AuthType SSPI
SSPIAuth On
SSPIAuthoritative On
SSPIOfferBasic On
SSPIOmitDomain On
# SSPIBasicPreferred
# SSPIUsernameCase lower
require group "UNITY\Domain local group name"
/Location
/IfModule

I spent some time this week preparing my app building workstation with a recent WolfPrep image and a restore partition configured the way I need it. Since I reboot and rebuild this machine often while building apps, I need a configuration that can reboot and rebuild quickly. This means no double-boot at startup and restoring from a backup image must be fast.

Confession... until recently, I had been using the very old method of "press 1 to rebuild" along with Ghost. This used the ancient Boot Control (BC.COM) program and a FAT16 restore partition. What I would do is install my machine using WolfPrep with "No Apps", save a Ghost image of the NTFS partition, run the old lab installer, and then copy my WolfPrep image to THISPC.GHO on the restore partition.

This worked well. Rebuilds only took 6-7 minutes and reboots were only 3 seconds longer than a normal Windows XP boot. Imaging only relied on Ghost which is stable and simple.

Unfortunately this no longer works. A Ghost image of a WolfPrep'd machine with no apps is just over 2GB. The FAT16 restore partition couldn't accomodate this because its limit is 2GB.

Rather than change the old lab installer to use FAT32, I wanted some more practice using Microsoft's WIM imaging technology along with Windows PE 2.0 which will be used in the new environment.

The end result is a machine with a FAT32 restore partition and an NTFS Windows XP/WolfPrep partition. This restore partition has Windows PE installed and is the location where restore images are saved. It is also the active partition. When the machine boots, it uses the Windows PE 2.0 (aka Vista) boot loader and presents a menu. You can either boot to Windows PE and restore the NTFS partition or boot normally to Windows XP.

Here is how I configured it:

Install a machine using WolfPrep.

Boot to the Windows PE 2.0 CD. This is available for free in the Windows Automated Installation Kit (WAIK).

Save a WIM image of the WolfPrep partition using the ImageX utility. The easiest way is to save the image to a separate drive, but you could also use ImageX to shrink an existing partition and then create a new partition.

D:\imagex.exe /caputure C:\ E:\wolfprep.wim "WolfPrep Partition" /compress maximum

Repartition and format the hard drive using DISKPART:

D:\> diskpart

select disk 0
clean
create partition primary size=10000
select partition 1
active
format quick fs=fat32 label="Restore"
create partition primary
select partition 2
format quick fs=ntfs label="WolfPrep"

Apply the WolfPrep image to the NTFS partition:

D:\imagex.exe /apply E:\WolfPrep.wim F:\

Apply the Windows PE image to the FAT32 partition:

D:\imagex.exe /apply D:\SOURCES\BOOT.WIM 1 C:\

You now need to configure the Windows PE boot loader. This can be a little confusing at first. Windows Vista no longer uses ntldr or boot.ini. The boot.ini file is replaced by a BCD file. This file is configured using the bcdedit command. There are other utilities to make this easier but I wanted to learn bcdedit. To configure the Windows PE (Vista) boot loader:

REM %CD% is the CD drive letter
REM %RESTORE% is the restore partition drive letter

xcopy %CD%\boot\*.* /e /f %RESTORE%\boot\

copy %CD%\bootmgr %RESTORE%

del %RESTORE%\boot\BCD

if not exist %RESTORE%\temp mkdir %RESTORE%\temp

del %RESTORE%\temp\BCD

Bcdedit -createstore %RESTORE%\temp\BCD

Bcdedit -store %RESTORE%\temp\BCD -create {bootmgr} /d "Boot Manager"

Bcdedit -store %RESTORE%\temp\BCD -set {bootmgr} device boot

Bcdedit -store %RESTORE%\temp\BCD -create /d "Windows PE" -application osloader

Bcdedit -import %RESTORE%\temp\BCD

The last command outputs a GUID number. Replace %GUID% with this number in the following commands:

xcopy %RESTORE%\Windows\System32\Boot\*.* %RESTORE%\Windows\System32\*.* /e /y

Bcdedit -store %RESTORE%\boot\BCD -set %GUID% osdevice partition=%RESTORE%

Bcdedit -store %RESTORE%\boot\BCD -set %GUID% device partition=%RESTORE%

Bcdedit -store %RESTORE%\boot\BCD -set %GUID% path \windows\system32\winload.exe

Bcdedit -store %RESTORE%\boot\BCD -set %GUID% systemroot \windows

Bcdedit -store %RESTORE%\boot\BCD -set %GUID% winpe yes

Bcdedit -store %RESTORE%\boot\BCD -set %GUID% detecthal yes

Bcdedit -store %RESTORE%\boot\BCD -displayorder %GUID% -addlast

xcopy.exe /H %WOLFPREP%\boot.ini %RESTORE%\

xcopy.exe /H %WOLFPREP%\ntdetect.com %RESTORE%\

xcopy.exe /H %WOLFPREP%\ntldr %RESTORE%\

bcdedit /create {ntldr} /d "Windows XP"

bcdedit /set {ntldr} device boot

bcdedit /set {ntldr} path \ntldr

bcdedit /displayorder {ntldr} /addlast

bcdedit /timeout 3

That's it. Now when I boot my machine I am presented with a menu that times out after 3 seconds. If I boot to Windows PE, I can restore my NTFS partition using ImageX /Apply in about 4 minutes.

In the manner parallel to the production forest, unqualified joins of new computers to TESTITD will now default to the OU location of Unassigned.Unity Computers.

This was accomplished by running:

REDIRCMP.EXE with the parameter of:
"OU=Unassigned,OU=Unity Computers,DC=testitd,DC=ad,DC=ncsu,DC=edu"

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.

This post describes some tests that were conducted to confirm the behavior of the sAMAccountName attribute and if disabling NetBIOS over TCP/IP has any effect on it.

My believe is that the sAMAccountName attribute must be unique across the entire domain even if NetBIOS is disabled on every machine and server. This assumption is based on Microsoft's documentation regarding security principals. Computer, user, and group objects are security principals. Each of these has a mandatory sAMAccountName attribute.

READ MORE

It's not done yet, but I'm in the process of moving our subversion repositories off of the venerable wolfprep.unity.ad server, so we can retire it.

When the move is completed, the WolfPrep stuff will all be located under https://svn.unity.ncsu.edu/svn/wolfprep

I've also got a new repository to share things not related to WolfPrep, https://svn.unity.ncsu.edu/svn/itdmicrosys . I hope to have the Remedy to AD group syncronization code, and the KMS license server monitor scripts posted up there "shortly."

Using subversion not only helps keep our source code managable, but it's sooo nice to have anonymous web browser access to things for information sharing and to encourage collaboration. We hope to regularly 'trade code' with groups on campus who have already solved problems that we're just getting our toes into.

Microsoft Virtual PC can be used to easily install and test ITD's new environment and installation methods without having to sacrifice any hardware.

Disclaimer: This is not any sort of announcement that people outside of ITD should test the new environment.

What you need:
Microsoft Virtual PC 2007 (Download)
ITD's Pilot Installation CD ISO (Download)

Configure Virtual PC
Install Virtual PC and create a new virtual machine. Configure the virtual machine to use at least 10 GB of hard drive space and at least 512 MB of memory. (Yes, these numbers are arbitrary)

Important: You need to select your wired network adapter under the virtual machine's networking settings. A wireless card, Shared Networking (NAT), and "Local only" probably won't work.

Virtual PC assigns a different MAC address to each virtual machine and these MAC addresses are not the same as the one your host PC is using. You need to register the virtual machine's MAC address in QIP and configure it to use M-DHCP.

If you already have another virtual machine that is using a MAC address registered in QIP, you can force the new virtual machine to use the same MAC address so you don't have to register another one.

Open the following file to view or modify the MAC address that the virtual machine will use:
My Documents\My Virtual Machines\*VM NAME*\*VM NAME*.vmc

You should see a line like this:
[ethernet_card_address] type="bytes"0003FF0E9EC2/[ethernet_card_address]

Note: greater than and less than signs were replaced with brackets in the line above because the blog software gets confused.

This line can be edited to use a MAC address that has already been registered in QIP to use DHCP from another one of your virtual machines. If you haven't already registered an address, use the MAC address from this line when configuring QIP.

Boot to the Installation ISO Image
From the CD menu in Virtual PC, select "Capture ISO Image" and then select the location of the pilot-install.iso file that you downloaded. Start the virtual machine and it should boot to the ISO file and Windows PE should start up. You should not have to do anything after this point thanks to Microsoft's "Zero Touch Installation" magic. The operating system should install, add the appropriate drivers, add the virtual machine to the domain, and eventually you should see the Windows XP logon box.

Tip: When Windows PE boots up, press F8 when you see "Initializing Windows PE".

This will cause a command box to appear. This is useful if you have any trouble. The most likely problem will be if networking isn't working. You can run ipconfig /all to make sure the virtual machine successfully receives the IP address you registered.