May 23rd, 06
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…
May 16th, 06
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:
- Sysinternals “psexec.exe” must be in place in “c:\local\bin”.
- The WinSSHD installer must be located in “c:\install”
- A WinSSHD server configuraiton file named “cat_config.wat” must be in place in “c:\install”
- 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.
May 15th, 06
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).
<!-- begin hide
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;
// end hide –>
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.
May 15th, 06
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:
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:
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 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:
REM Determine if host is running a Windows XP build:
ver | find /i "xp" && set OSVer=XP
IF NOT %OSVer%==XP GOTO unsupported ELSE goto spLevel
REM Determines Service Pack Version via registry query:
REM systeminfo |find "Service Pack 1" && set SPVer=1
REM systeminfo |find "Service Pack 2" && set SPVer=2
reg QUERY HKLM\SYSTEM\CurrentControlSet\Control\Windows /v CSDVersion | find "0x200" && set SPVer=2
IF NOT %SPVer%==2 GOTO unsupported ELSE GOTO addRules
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,220.127.116.11/16 profile = ALL
IF %errorlevel% GEQ 1 (
) 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,18.104.22.168/16 profile = ALL
IF %errorlevel% GEQ 1 (
) ELSE (
ECHO Firewall rule added successfully.
ECHO Your system is not running XP with Service Pack 2.
ECHO You do not need firewall exceptions added to your system.
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 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 Product setup complete.
ECHO Firewall exceptions script failed!
ECHO Symantec AntiVirus NOT INSTALLED.
ECHO Take your system to Walk-in help.
Mar 17th, 06
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
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:
– General how-to on using .asp custom error pages for client side redirect… includes security configuration details, but lacks specific syntax.
– 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.
– Another ASP redirect script.
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!
Mar 10th, 06
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):
This manual comes from the following page:
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.
Mar 3rd, 06
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:
- Install the Windows AIK
- cd %ProgramFiles%\Windows AIK\Tools\x86 (this directory contains all of the CLI tools for WinPE image building)
- mkdir \winpebuild\build
- 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)
- To install additional network drivers to the PE build:
peimg /inf=[path to NIC driver INF] c:\winpebuild\build\windows
- copied “ximage.exe” and all other .dll files from the working AIK directory to c:\winpebuild\build\windows\system32
- 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.)
- 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
- 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
- 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
- copy bootmgr c:\winpe
- 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)
- 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”?)
- 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!!!!
Mar 3rd, 06
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:
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.
Feb 28th, 06
I am attempting to set up a test sharepoint server environment to deploy the current production environment. This will contain a copy of the prod sharepoint Content DB, and will reflect the same general conrfiguration:
-separate service account for Sharepoint content managment and Sharepoint configuration
-SQL DB server and Sharepoint web components run on separate OS instances
-Sharepoint installed on non-default IIS site, using host headers to direct users to the secondary IP (do we really need a secondary IP???)
I am having some difficulties around Kerberos auth and also with prod DB import. Here are some helpful links:
Feb 28th, 06
It seems that some of our constituients have not been paying overly much attention to the settings on their scanners. We have over 40Gb of black-and-white, text-only documents scanned at 24 BPP, uncompressed, consuming 10 Mb each!
This happened once before. My colleague Warren licensed a product called “2TIFF” to shrink the files in question. This works well, except in his case ALL of the images in an Application folder needed to be compressed. I only need to shrink SOME of them.
After much fooling around and wasting of time, I was able to use a win32 port of the UNIX “find” command to hunt down all of the large files, dump the list to a file, and then use this file as a source for 2TIFF. The big mess of images now occupies only about 30 Mb of space.
Here are the sommand syntax details:
> find.exe “I:\OBJECTS\PURCHASE_ORDERS” -size +3M -fprint bigfiles.txt
(searches the PURCHASE_ORDERS document tree for all files larger then 3 Mb, dumps results to the text file “bigfiles.txt)
> FOR /f %F in (bigfiles.txt) DO ( “C:\Program Files\2TIFF\2tiff” s=%F d=%~dF\shrink%~pF -namegen=”[name].[srcext]” -quantize8 -ct4 -cd4 -keepexif)
(Perform a loop operation. For each loop, set the next line in bigfiles.txt to the variable %F. Run the 2Tiff program using %F as the source file. Use \shrink as the output directory (example: when %F=”c:\objects\procurement\1\163.bin, the output directory will be “c:\shrinkProcurement\1\”).)
Here is what the 2Tiff arguments mean:
-namegen=”[name].[srcext]” -> The name of the destination file is the same as that of the source ([name] is a built in variable equal to the source file name. [srcext] equals the source file’s extention)
-quantize=8 -> sets the “quantization” level of the TIFF. This value effects the “sampling rate” and affects image quality. Eight is the maximum value, for best quality.
-ct4 -> Compression type “LZW” is used. This is the default type for color scans. We are using LZW rather than the standard “type 3″ for B/W documents because tests showed that reducing these images to monochrome yielded very low quality in some cases. We are keeping some color information to allow anti-aliasing and thus better letter quality.
-cd4 -> Sets the color depth down to 4 BPP from the source 24 BPP. CD1 would be better, but as mentioned above, this results in poor readability of the destination TIFF.
-keepexif -> preserves EXIF tags in the destination file from the source. Probably there is no EXIF info in these files, but I thought we would keep it in case I am wrong.
Warren had used the “dither” switch, but IMNSHO this makes the target document look worse and also results in larger files.