WDS – Migrating images from RIS to WDS

WDS has a native utility for converting legacy RIS images to WIMs. I am trying it using the Spring 2006 CAP image.

 Oh look… it does not work!  I have submitted a bug using the Beta reporting tool.  Hopefully someone will pick it up.

Installing Project Server 2007, Beta 2

I have brought up a new test server to give Project Server 2007 a whirl. Here are some of the gotchas in the install process:

  • Install required "Windows Workflow Foundation, Beta2". I downloaded v2.2 from here:
    http://www.microsoft.com/downloads/details.aspx?familyid=5C080096-F3A0-4CE4-8830-1489D0215877&displaylang=en
  • Also required is ASP.NET 2.0, which is installed with the .NET Framework 2.0 components (available on Microsoft Update, or as a standalone installer. Apparently my .NET 2.0 was damaged, so I ran a repair install. After ensuring that ASP.NET was enabled in IIS, the Project Server installer now runs without complaint.
  • Project Server has an "all in one box" installation option. This installs and configures Sharepoint Services 3.0 and SQL 2005 Express Edition. It works surprisingly well!

Also note that the test server performing miserably.  I have expanded the VM memory to 1Gb, and performed the following steps to expand the virtual drive:

  •  execute: vmware-vdiskmanager -x 15Gb <Path to.vmdk file>
  • Boot to BartPE CD with Paragon Partition Manager, expanded system drive.

Ximage success

I finally was able to generate an image of my Win2k3 VMWare reference system using Ximage (soon to be renamed “ImageX”).

In the past I had many problems, although not strictly related to the utility itself:

  • Networking in VMWare workstation for the WinPE 2.0 beta in the Vista AIK will not function! Apparently this is a driver issue. There is a bug registered in the Vista beta program, but I never did follow up on it.
  • Networking in WinPE 1.5 did work, roughly speaking, but getting it all to function was like pulling teeth. WinPE 1.x kinda bites (not very user friendly)
  • BartPE networking works great! Unfortunately, getting the “C:” drive to mount on my VMware Workstation instance was a bit more difficult. Some forum hopping revealed that others who attempt to use Server 2003 SP1 as the source for the WinPE build also have this problem. By changing the source to Server 2003 RTM, I am now able to mount the C: drive, and thus run XImage.exe.

XImage throughput was comperable to Ghost 8, and achieved almost identical compression ratios. CLI syntax is pretty straightforward. I think we have a winner…

WinSSHD software deployment – scripted

The Catalyst team asked me to evaluate and install an SSH/SFTP/SCP service for them on all of the CATXXX Windows servers. After some evaluation and testing, we settled on bitvise WinSSHD. To “save time” I decided to try scripting the install.

Here is the process that I came up with:


for /f %%s in (catserv.txt) do copy /v /y c:\install\WinSSHD-Inst.exe \\%%s\c$\install\WinSSHD-Inst.exe
for /f %%s in (catserv.txt) do copy /v /y c:\install\cat_config.wst \\%%s\c$\install\cat_config.wst
c:\local\bin\psexec.exe @catserv.txt "c:\install\WinSSHD-Inst.exe" -site=WinSSHD -acceptEULA -activationCode=[insertCodeHere] -settings=c:\install\cat_config.wst
for /f %%s in (catserv.txt) do sc \\%%s start winsshd
for /f %%s in (catserv.txt) do sc \\%%s query winsshd | find /i "running" >> isrunning.txt

Note that this script required a few files to be in place before execution:

  1. Sysinternals “psexec.exe” must be in place in “c:\local\bin”.
  2. The WinSSHD installer must be located in “c:\install”
  3. A WinSSHD server configuraiton file named “cat_config.wat” must be in place in “c:\install”
  4. This script and the catserv.txt file must be present in “c:\local\scripts”. The catserv.txt file contains a simple list of the servers to which WinSSHD will be installed.

Redirecting HTTP to HTTPS, part DUH.

It always helps to know what you are doing…

After much head bashing and tooth gnashing, I discovered that the real reason that most people recommending a solution to this problem present a client-side redirect is pretty simple:

When browsers swith from a http:// rooted URI to a https:// rooted URI, they effectively assume that they are switching to a new website (which, effectively, they are).

So, I implemented a client-side redirect by replacing the default “https required” IIS 403.4 error page with a custom page containing this javascript code:


<Script language="JavaScript">
<!-- begin hide

function goElseWhere()
{

var oldURL = window.location.hostname + window.location.pathname;

var newURL = “https://” + oldURL;

query = ” + window.location;
position = query.indexOf(‘?’);
if (position > -1)
{
query = query.substring(position + 1);
newURL = newURL + “?” + query;
}

window.location = newURL;

}
goElseWhere();

// end hide –>
</script>

Unfortunately, this still does not work for MS Office programs. Office refuses to recognize a redirect request (be it either server or client based), so anyone attempting a manual save to an http:// rooted URI will just get an error. Nothing to be done for it… it is an office bug. Report it to the Office team, it is not my fault.

Additional SAV installer builder instructions, updated script

Upon reviewing my earlier notes on building installers, it appears that I left out some useful info on how to build the darned administrative installation point that I am using to wrap up the patched installer. Since I had the “opportunity” to work on a v10.1.0.400 installer today, I will take this opportunity to actually document my installer builder process:

  • open a CMD shell, CD to the SAV directory on the Symantec installation media
  • extract the MSI files to a local “administrative installation point”:
    msiexec /a "Symantec Antivirus.msi"
    
  • Now, extract any patches downloaded from Symantec and CD to the directory that has the MSP patch file. Execute the following:
    msiexec /p "SAVCE-[version].msp" /a [path to admin install point] 
  • Now, copy the setup.exe, setup.ini, msi installer files, and that .ini file with the funny name from the SAV source directory into the “administrative installation point” directory used above.
  • Edit the “setup.ini” file in your admin install point. Modify the product version string to more closely match the version just overlayed onto the installer.
  • Copy in your custom SAV installer script. (In our case, we use “instsav.cmd”). Generally I just copy his out of the last production installer. Also grab the sav-managed.txt and sav-unmanaged.txt files from the previous installer. These just contain informational text to be pasted into the self-extracting archive prompt dialogs.
  • Now you can wrap the whole directory into a self-extracting archive, which spawns “instsav.cmd” when extraction is complete. Of late, I have been using WinRAR. Since the 10.0.1 builds, I have been extracting the archive to “%SYSTEMDRIVE%\SAVInst”, with the option to leave the extracted files in place after installation (thus creating a local installation source). You may note that the instsav.cmd installation script uses this directory path to launch the setup.exe program.

Also note that I have made some significant changes to the instsav.cmd script. Mostly I just deleted unused sections of the script… version 10.1 does not appear to bog down the computer doing “startup scans” and “Definition scans” as earlier versions did, so I am removing the custom registry key imports that halted these scans. Also, I changed the IF NOT ERRORLEVEL 1 clauses to use the syntax “IF %ERRORLEVEL% GEQ 1″ instead, as this seems rather easier to understand from a logical perspective, IMO. Anyway, here is the script:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
:begin
@ECHO OFF
ECHO - Symantec Antivirus installation script for the University of Vermont
ECHO - version 2.6, by JGM, 2006-05-15
ECHO - This Window will close automatically when installation has completed.
REM Script can be altered to allow for either managed or unmanaged client installations.
REM For managed installs, UN-comment the "goto endFirewall" line below, and uncomment the appropriate "setup" command line.
REM For unmanaged installs, COMMENT OUT the "goto endFirewall" line below, and uncomment the appropriate "setup" command line.
REM History:
REM V2.3 - changed "reg import" commands to "regedit /s" commands for Windows 2000 compatibility.
REM v2.5 - changed setup to generate MSI error log (/le option), and to run out of %SystemDrive%\SAVInst dir created by RAR extractor.
REM v2.6 - removed the "removeStartScan.reg" procedure after the :endFirewall tag, and an experiment for v10.1.x distribution, cleaned up un-used sections, substituted "IF %errorlevel% GEQ 1" instead of "IF NOT errorlevel 1" as a experiment.
REM If performing an unmanaged AntiVirus client installation, uncomment the following line:
GOTO endFirewall
:OSVer
REM Determine if host is running a Windows XP build:
set OSVer=notXP
ver | find /i "xp" &amp;&amp; set OSVer=XP
IF NOT %OSVer%==XP GOTO unsupported ELSE goto spLevel
:spLevel
REM Determines Service Pack Version via registry query:
set SPVer=0
REM systeminfo |find "Service Pack 1" &amp;&amp; set SPVer=1
REM systeminfo |find "Service Pack 2" &amp;&amp; set SPVer=2
reg QUERY HKLM\SYSTEM\CurrentControlSet\Control\Windows /v CSDVersion | find "0x200" &amp;&amp; set SPVer=2
IF NOT %SPVer%==2 GOTO unsupported ELSE GOTO addRules
:addRules
ECHO.
ECHO.
REM Adds firewall exceptions for Windows XP SP2 hosts:
ECHO - You have Windows XP Service Pack 2!  Let's Go...
ECHO - Please wait while firewall exception rules are added...
ECHO Adding exception for Symantec Realtime Virus Scan to allow managmenet of SAV Client
@netsh firewall add portopening protocol = UDP port = 2967 name = "Symantec RTVScan" mode = ENABLE scope = CUSTOM addresses = LocalSubnet,127.0.0.1,132.198.0.0/16 profile = ALL
IF %errorlevel% GEQ 1 (
	GOTO failRuleAdd
	) ELSE (
	ECHO Firewall rule added successfully.
	)
@netsh firewall add portopening protocol = UDP port = 38293 name = "Intel PDS (Symantec AV)" mode = ENABLE scope = CUSTOM addresses = LocalSubnet,127.0.0.1,132.198.0.0/16 profile = ALL
IF %errorlevel% GEQ 1 (
	GOTO failRuleAdd
	) ELSE (
	ECHO Firewall rule added successfully.
	)
GOTO endFirewall
:unsupported
ECHO.
ECHO.
ECHO Your system is not running XP with Service Pack 2.
ECHO You do not need firewall exceptions added to your system.
GOTO endFirewall
:endFirewall
ECHO.
ECHO.
ECHO Deleting log files from previous installations...
@del /f /s /q "%ALLUSERSPROFILE%\Application Data\Symantec\Symantec AntiVirus Corporate Edition\7.5\Logs"
IF %errorlevel% GEQ 0 (
	ECHO No previous Symantec AV log files needed to be deleted.
	) ELSE (
	ECHO Symantec AV Log files successfully deleted.
	)
@del /f /s /q "%ALLUSERSPROFILE%\Application Data\Symantec\Norton AntiVirus Corporate Edition\7.5\Logs"
IF %errorlevel% GEQ 0 (
	ECHO No previous Windows 2000/XP Norton AV log files needed to be deleted.
	) ELSE (
	ECHO Norton 2000/XP AV Log files successfully deleted.
	)
ECHO.
ECHO.
ECHO Proceeding with SAV install...
REM One of the following two "setup" lines MUST BE COMMENTED OUT!
REM installation string for an UNMANAGED client install (intended for off-campus users):
"%SystemDrive%\SAVInst\setup" /s /qn /V"/qb /le %SystemDrive%\SAVInst\install.err REMOVE=Pop3Smtp,NotesSnapin ADDLOCAL=SAVMain,SAVUI,SAVHelp,QClient,OutlookSnapin NETWORKTYPE=2 RUNLIVEUPDATE=0 SYMPROTECTDISABLED=1"
REM installation string for a MANAGED client install (intended for systems that are frequently on-campus):
REM "%SystemDrive%\SAVInst\setup" /s /qn /V"/qb /le %SystemDrive%\SAVInst\install.err REMOVE=Pop3Smtp,NotesSnapin ADDLOCAL=SAVMain,SAVUI,SAVHelp,QClient,OutlookSnapin NETWORKTYPE=1 SERVERNAME=NORTON2 RUNLIVEUPDATE=0 SYMPROTECTDISABLED=1"
ECHO.
ECHO.
ECHO Product setup complete.
GOTO end
:failRuleAdd
ECHO.
ECHO.
ECHO Firewall exceptions script failed!
ECHO Symantec AntiVirus NOT INSTALLED.
ECHO Take your system to Walk-in help.
pause
GOTO end
:end

Redirecting HTTP traffic to HTTPS in IIS

What a pain… I shore up security in IIS I reallly will need to redirect all traffic on sharepoint to HTTPS connections. It is easy to turn on SSL, but harder to automatically redirect traffic. There are many approaches to this problem, which take the form of two basic solutions:

  • Client side redirection
  • Server side redirection

With the first approach, we direct the client to a custom error page that tells the browser to reconnect to the same URI, but with an HTTPS protocol. This can be done with javascript or .asp. Either way, the disadvantage is that form and query data likely will be lost in the dedirect. At least with the Javascript approach, you lose browse ability from MS Office applications as well.

The second approach will rewrite the URL at the server, thus preserving all URL data such as form and query info. However, this approach requires custom code to be added to IIS in the form of either an ISAPI filter or web service extension. These add-on programs frequently have conflicts with the STSFLTR (Sharepoint ISAPI filter).

I have tried a lot of junk… here are some links:
http://weblogs.asp.net/pwilson/archive/2004/12/23/331455.aspx
– General how-to on using .asp custom error pages for client side redirect… includes security configuration details, but lacks specific syntax.

http://www.codeproject.com/aspnet/WebPageSecurity.asp
– A powerful ASP.NET module to be added to your site config files. This allows per-directory auto-SSL redirection. Looks promising, but it is too much for my feeble mind to precess at present.

http://blog.opsan.com/archive/2005/10/19/1979.aspx

– Another ASP redirect script.
Note that in the feedback on this page is some excellent Javascript to accomplish client side redirection… I think this is the solution I will have to go with.

I also have tried (extensively) several ISAPI filters which emulate the Apache “mod_rewrite”. This filters work great on other IIS web sites, but not with Sharepoint… GRRRR!

Using BartPE for system cloning

I have come across the need image sevaral servers in preparation for migrating them to new “hardware”. (The actual situation is that I have several systems running on VMWare Server Beta (formerly GSX Server), and I want to migrate them to ESX server. Since the two virtual servers use different disk formats, I cannot simply copy the virtual disks, I need to clone them using some other third-party tool. Further complicating the matter is that I plan to install ESX server on the SAME HOST that is currently running GSX, and ESX wants to take control of the ENTIRE local hard drive.)

After exploring the options, I decided to take advantage of our existing license pool for Symantec Ghost 8.0 (I had considered using MS XImage, but I am still seeing this as a beta product, and more trouble than it is worth on this particular project). Now the question is HOW to use Ghost.

I came across this excellent resource for “P2V” migrations, which also should work well for V2V (Virtual to Virtual):

http://www.rtfm-ed.co.uk/docs/vmwdocs/whitepaper-ultimateP2V-QuickStart.pdf

This manual comes from the following page:

http://www.rtfm-ed.co.uk/?cat=10

So, “all I had to do” was download pebuilder (which I had already done), drop the vmxnet and vmscsi drivers into the appropriate pebuilder drivers directory (already done), then activate the additional plug-ins that they provide for the vmware tools. I then needed to switch my pebuilder sources from the windowx XP i386 directory to a server 2003 i386 directory.

Ghost configuration was really easy, as pebuilder already has a ghost 8 plug in. I jest needed to extract the ghost files documented in the plugin help file into the pebuilder directory structure. Voila!

A few minutes later I had an .iSO which I mounted on VMWare and successfully booted! I am able to use “net use” to map a network drive, and then run ghost32.exe to dump an image to a separate workstation on the network.

WinPE: Building from the Windows Vista AIK Beta

So, workstation image capture is now performed using “XImage.exe” (soon to be renamed ImageX.exe). Although multiple capture methods are supported, use of Windows PE 2.0 is encouraged.

I obtained the February CTP of the Windows Automated Installation Kit (AIK). This contains several utilities for working with and creating Windows “WIM” image files, and also includes WIMs for Windows PE 2.0.

Here is the process I am working on for building a bootable Windows PE image:

  1. Install the Windows AIK
  2. cd %ProgramFiles%\Windows AIK\Tools\x86 (this directory contains all of the CLI tools for WinPE image building)
  3. mkdir \winpebuild\build
  4. ximage /apply boot.wim 1 c:\winpebuild\build (this extracts image index “1″ from the boot.wim in the AIK directory to the specified build directory. All of the WinPE files are now available on the local NTFS drive)
  5. To install additional network drivers to the PE build:
    peimg /inf=[path to NIC driver INF] c:\winpebuild\build\windows
  6. copied “ximage.exe” and all other .dll files from the working AIK directory to c:\winpebuild\build\windows\system32
  7. Now save a copy of the working build directory, as the next step will make irreversable changes to the build directory:
    ximage /capture c:\winpebuild\build c:\images\winpe1.wim “Custom Base Image” /compress /max
    (this captures the build directory to a WIM file “winpe1.wim” with descriptor “Custom Base Image”, using maximum image compression to save drive space.)
  8. Now we prepare the build directoryfor capture. This step optimizes the build, but also prevents future use of the “peimg /inf” command:
    peimg /prep c:\winpebuild\build\windows
  9. Now we generate a WIM file of our customized build:
    ximage /capture c:\winpebuild\build c:\winpebuild\boot.wim “WinPE Image with VMWare Drivers” /boot /compress max
  10. In the next steps we create a separate directory structure which from which we will build a bootable .ISO WinPE image:
    mkdir \winpe\sources, mkdir \winpe\boot
  11. copy bootmgr c:\winpe
  12. xcopy /cherky .\boot c:\winpe\boot (relative to the working x86 AIK directory) (these three steps add files necessary for building a bootable ISO to the directory structure)
  13. ximage /boot /export /compress max c:\winpebuild\boot.wim 1 c:\winpe\sources\boot.wim (copies the custom WIM to the new directory scructure… I wonder if I could just use “xcopy”?)
  14. oscdimg /n /b.\boot\etfsboot.com c:\winpe c:\winpe.iso (creates a bootable ISO from the boot.wim using the boot code in “etfsboot.com”.)

AARGH! It just does not work still! No networking is available when I boot to WinPE!!!!

Windows Deployment Services – Installing on VMWare

Got my hands on the WDS beta from Microsoft. Looks like a huge improvement on RIS, although the documentation really leaves something to be desitred at this point. Key features:
– Image-file based service. Uses the new “WIM” image format.
– Tools provided to edit WIM images (ie. drop in Microsoft Hotfixes and service packs)
– Improved GUI and CLI tools for managing images
– Unified answer file format for all installations
– Migration tool to allow RIS file-based image to WIM image conversion!
– WinPE-based process, uses “real” network drivers, and has more client-side options for image capture (ie. capture to local image, capture to network share). Capture can be performed independently from the WDS server.

Anyway, I installed WDS on a VMWare instance of 2003 SP1 server. The procedure was fairly straightforward:
– Install Remote Installation Services from the Add/Remove Windows Components Wizard
– Install the WDS “hotfix” (this changes the name of the RIS service from “binlsvc” to “WDSServer”.
– Initialize WDS using either the CLI “WDSUtil”. I used the CLI, but it would seem that the GUI may be better as there is more thorough prompting for installation image media.

Following installation, I had some trouble getting another VMWare host to net-boot to the WDS server. I then tried isolating the hosts onto the VMWare “host-only” network with no further luck. Eventually I read the VMWare documentation:

http://www.vmware.com/support/gsx3/doc/network_host_gsx.html

As it turns out, VMWare runs a virtual DHCP server on the host-only and NAT virtual network adapters (this is kind of a “duh” if you think about it. By going into the VMWare “Host” menu, then selecting “Virtual Network Settings”, I am able to disable the DHCP server. Now my other virtual hosts boot to the WDS server promptly. Cool!

Now I just have to igure out how to get some images into the system…

I plan to switch to NAT networking so that I can communicate with external systems where I intend to capture the WIM images.