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!
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.
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 AIKToolsx86 (this directory contains all of the CLI tools for WinPE image building)
- mkdir winpebuildbuild
- ximage /apply boot.wim 1 c:winpebuildbuild (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:winpebuildbuildwindows
- copied “ximage.exe” and all other .dll files from the working AIK directory to c:winpebuildbuildwindowssystem32
- Now save a copy of the working build directory, as the next step will make irreversable changes to the build directory:
ximage /capture c:winpebuildbuild c:imageswinpe1.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:winpebuildbuildwindows
- Now we generate a WIM file of our customized build:
ximage /capture c:winpebuildbuild c:winpebuildboot.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 winpesources, mkdir winpeboot
- copy bootmgr c:winpe
- xcopy /cherky .boot c:winpeboot (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:winpebuildboot.wim 1 c:winpesourcesboot.wim (copies the custom WIM to the new directory scructure… I wonder if I could just use “xcopy”?)
- oscdimg /n /b.bootetfsboot.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!!!!
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.