In an effort to be fair…

Everyone gripes about Microsoft being all about money and whatever, perhaps they should take the approach that it appears RedHat Enterprise is taking. Just giving the stuff away to anyone who has an email account! This has got to be the coolest thing I’ve ever seen before!

 

Ok, in all fairness I do have a RedHat account, but it was an account I had to create to download the "eval" copy of RHEL 5.1, so it’s for all intents and purposes blank, no account number, no account activity, well…until this morning.

 

Here is the email I received and only the account numbers have been changed to protect the innocent!

 

From: Red Hat Alert [appredhi@redhat.com]
Sent: Friday, March 14, 2008 8:41 AM
To: jeffpatton@ku.edu
Subject: Red Hat Order Notice

 
Dear Red Hat Customer,

Thank you for your order for Red Hat Subscription Services. Red Hat has
received and processed the following order on your behalf.

If you have any questions regarding this order, please contact the partner
from whom you purchased your subscription.

For Customer Service questions, please contact your regional Red Hat Customer
Service Representative using the contact information provided at the following
link: http://www.redhat.com/about/contact/dir/#custservice

Account Number          : #####
Contract Number         : #####
Red Hat Reference Number: #####

Order Details:     
***************************
Line 1
Quantity   : 22
Description: Red Hat Enterprise Linux (Academic Edition)
***************************
    

Thank you for choosing Red Hat.

Sincerely,
Red Hat Account Management Team

This message was automatically generated.

 

As I said I don’t have anything on my account, here you will a screenshot of my account!

 

Normally you would see something like the following!

 

The black box would have an account number listed which btw, the account number listed in the email is completely different from the account number listed on the website. I’m seriously considering calling RedHat and asking why I don’t see 22 licenses for Enterprise on my account!

 

Ok partial of a phone conversation that happened recently, RedHat is trying to explain why…

Gedanken: apparently somehow, jeffpatton because associated as a purchasing agent for our account

This was verbatim what was said…

How true it is….

I found this while searching for using GTK on Windows. Here is the thread.

Quote

Originally posted by The Shadow:
You know, funny thing is, they said the same thing about XP’s animations when XP came out – 5 years ago. But most 2002-vintage machines don’t run XP very well unless they’ve been pretty heavily upgraded. I don’t really see Vista as being any different in that respect.

Not just there, most of the complaints about Vista are also the complaints people said about XP and Win2K when they were released. Right down to the same catch phrases and statements.

Bloated… blah blah… resource hog… blah blah… incompatible… blah blah… wait for SP1… blah blah…

It’s actually almost comical.

The “new way” or Software Lifecycles

 

Currently we have a very poor methodology of managing the host of software applications that we support on our network. The process is as follows:

New Software Request

Faculty: I need application xyz.exe installed for my class

Staff: Ok

Student: Application xyz.exe doesn’t work, and I need this for a very important project

Staff: Ok

Faculty: Why doesn’t this application work, I can download it and run just fine on my computer at home.

Staff: Ok

Software Upgrade

Faculty: The latest release of xyz.exe is out today, we need this loaded on the labs.

Staff: Ok

Student: Application abc.exe doesn’t work anymore, and I can’t get xyz.exe to run widget.

Staff: Ok

Faculty: I don’t know why abc.exe doesn’t work, I don’t have that problem on my computer at home.

Staff: Ok

Do you see the problem? We have no formal process of evaluating the impact of a given application in our environment, and beyond that once we have a given application working, we have no procedure on how to deliver that software to the appropriate computers. This is where Software Lifecycle comes in to play. All software, regardless of it being new, or an upgrade to existing applications will go through the following process.

Step 1.

Install the application onto a test machine. The test machine will have the base load of software, consisting of Windows, Office and Sophos Anti-Virus.

Step 2.

Verify that the application will start, then have someone who is knowledgeable in the program to verify that it works under a regular user context. If there is a problem, research and resolve that problem and then test again. This process will continue until the application works.

Once the application has been verified to be functional it will then be packaged into an .msi file and installed onto a target machine. The target machine will exactly mirror the targeted lab environment in every single way.

Step 3.

Verify that the application will start, then have someone who is knowledgeable in the program verify its functionality. Document any issues that occur at this point, and resolve them. This process will continue until the application works. Once the application is functional then all applications that are already installed will be verified to work, if any issues are discovered document and resolve them.

Once the target machine functions any fixes will be packaged into the application prior to deployment.

Step 4.

Load the packaged application onto the distribution server, and configure the appropriate software deployment policy.

Another option would be to use System Center Configuration Manager to schedule the deployment of the application at a time when it will have the least impact on the lab and the students who may be using the lab. The benefit of this solution is the ability to schedule when an application gets installed as opposed to waiting for a computer reboot to occur.

Once this system is in place we can begin to develop a valuable documentation resource for our applications.

Why “Scorched Earth” can be a good thing.

 

Historically here in the School of Engineering, software installation was handled by a single person. What I mean by this is, if a faculty person required specific software to be installed, one individual would take the time to get that software to work. Little if any documentation was created as we relied on this one person to always be there.

Currently, our image is very poor. We lack the documentation, (documentation = knowledge), to properly configure the upwards of 60 unique applications needed by the various disciplines within the school. Consequently, when an application is found to be missing, or mis-configured it takes a significant amount of time to re-invent the wheel. Because of that confidence in our ability has suffered extensively.

So the only real solution is to start over, and in our environment the only real way for us to do this is to blow everything away. Come up with a new way of delivering the requisite service that faculty, staff, and most importantly the students require. To that end I have a very simple plan that I will begin to implement.

Step 1.

Create a new way to deploy software.

All software will be packaged into an easily deployed .msi file. Each .msi file will be deployed via GPO attached to the appropriate OU in the Active Directory.

Step 2.

On the first full week after classes end; systematically wipe and re-install each individual lab, using Windows Deployment Services combined with Managed Software Installation and Windows Software Update Services.

The end result should be a lab hat is fully configured and updated with software that works. I was intentionally vague on the "new way" process as I will detail that in a second posting, but this is basically the idea.

HOWTO: Deploy Windows XP via Windows Deployment Services on Windows Server 2003

 

1. Overview

The ability to deploy an OS via the network has been an important part of network administration for many years. Microsoft has provided tools to facilitate network installation since Windows NT 4.0, and with each evolution of the Operating System the tools have gotten more sophisticated and feature rich.

Remote Installation Services was introduced with Windows 2000 and it leveraged the new way of creating a Windows Network, Active Directory. It provided a much easier method of deploying the Windows OS to client machines, and the addition of "Plug and Play" to the core Windows OS, made it much easier to push the OS to disparate hardware.

With the release of Windows Vista a new way of deploying the Operating System is available. Windows Deployment Services, this can run within a Windows Server 2003 box, or you can configure the WDS Role in Windows Server 2008. One of the coolest features is the new imaging format, .wim.

A windows image file can be mounted in the same fashion you might mount an ISO file. Once mounted you are able to browse the file and add/remove files from it, the changes can then be committed when the image is unmounted. Not only are you able to "browse" the file the implication is that you could even deploy a service pack to the OS by simply mounting the .wim file, or possibly even installing an application into the .wim file. Another exciting feature is the ability for the file to contain more than one image within it.

An administrator can have one "image" and within that image can have images for each department, or function group within the organization. Like it’s predecessor’s this is a free add-on to the OS, there is no additional licensing requirements for running WDS, there is no additional charge for installing the role in Windows. It’s free to use to anyone who has the knowledge to leverage the technology.

2. Network Configuration

A minimum of two servers are required, one server will be the Domain Controller, DNS Server and DHCP Server. Technically the DHCP Server can reside on the WDS server, in fact it’s much easier now to have WDS and DHCP on the same server than it was under RIS. I configure it separate from WDS strictly due to habit out of using RIS.

Once your servers are installed, add the DNS, and DHCP services to the server that will become the Domain Controller. Configure DNS with the FQDN of your AD Installation, don’t worry that you haven’t run DCPROMO yet. Again, out of habit I configure DNS first due to an issue with Windows 2000 AD that has since been resolved.

Verify that DNS allows dynamic updates to both your forward and reverse lookup zones, then configure the DHCP service. Nothing special is needed for either DNS or DHCP, although I have taken to using exclusion ranges for RIS so only the machines I want to RIS have the ability to do so. Verify that your domain suffix is the FQDN of your AD Domain, verify that your Primary DNS is the IP Address of your soon-to-be Domain Controller, reboot the server.

Run DCPROMO and configure your AD Domain the same as the FQDN you configured in your DNS service. Reboot the server after the wizard is done and AD is successfully installed on your server. There is very little left to do on the Domain Controller once the AD Service has been installed.

3. Server Configuration

Configuring RIS is very straightforward, simply install the service on the second server, the only real requirement is a second drive in this box. It should be large enough to hold all the images you would like to make available, I will walk through configuring RIS as it is extremely simple.

Once the service is installed you are required to reboot the server, when it comes back up complete the setup by providing the first distribution image, it may be a Windows Server 2003 image or a Windows XP image, you could probably get away with a Windows 2000 Professional image, but I’ve never tried that. Then I usually run "adminpak.msi" to install the Windows Server 2003 Administrative Tools on the RIS Server. This allows you to open "Active Directory Users and Computers" so that you may configure the RIS Server itself.

First things, authorize the DHCP Server, you will be able to do this via the DHCP MMC, under Administrative Tools. You should be able to authorize the RIS server in the same fashion, if you have problems attaching to a PXE client to the RIS server then rebooting the RIS server usually resolves this problem, your mileage may vary.

Configuring WDS is even simpler, install Service Pack 2 on the RIS server, reboot the server, open the Windows Deployment Services console from "Administrative Tools" and add your server to the list. Once the server has been added to the list, select your server and then choose to "Configure the server", the most important part of this is specifying the location of the Remote Installation directory.

Your RIS server is now set to deploy regular RIPrep images as well as the new .wim format for Windows Vista and later Operating Systems.

4. RIS vs WDS

At a high level, both of these products do the exact same thing, take an "image" from the server and put it on the client. How this is accomplished by both is a little different.

RIS copies all the files from the server to the client and setup runs and configures the client machine and if you have scripted it via an unattend file, then it is totally hands-free. I’ve done some monitoring of a typical RIS session, network utilization goes up considerably but not the point to which it overwhelms or floods the network. A complete installation of Windows XP SP 2 took 27 minutes to complete, from beginning to end on a 100mb switched network.

I’ve not done the same monitoring of WDS as I did for RIS, but what I do notice is this install is more like a Windows Vista install than anything else. The image is deployed directly to the hard-drive, there is no setup to walk through, and any configuration there is could be scripted as well.

During a RIS install the clients each connect to the distribution share and download each file separately, whereas with WDS, the image file is accessed directly over the network. Fewer open files on the server, but the files are larger, overall I don’t see any appreciable difference performance-wise between the two.

5. What to do with RipRep Images

It is possible to convert RipRep images to the .wim format using the wdsutil command, it’s very straightforward, and has a very rich help system associated with it.

wdsutil /? gives help about the utility

wdsutil /Convert /? gives specific help about the convert option

wdsutil /Convert-Riprepimage /? gives help about converting RipRep images

wdsutil /Convert-Riprepimage /Filepath:"\RemoteInstall\Setup\English\Images\XP-Base-WithUpdates\i386\Templates\riprep.sif" /DestinationImage /Filepath:"\RemoteInstall\Images\XP-Base-WithUpdates.wim"

This converts a RipRep image of Windows XP with updates from the default location to a .wim file in a different directory, there are several options that go along with the process, I urge you to use the built-in help system to explore the commands available.

6. Capture vs Boot Images

Boot images allow a pxe client to boot and connect to a WDS server to deploy an image, or run some other utility. There are some interesting possibilities with WinPE. There are a variety of boot images you can choose from, there is a boot image on the WAIK, you can use an OEM boot image, or the boot image from a regular distribution DVD.

Capture images are created from boot images and allow the administrator to take a "snapshot" of a currently installed system and create a .wim file locally on the reference machine and optionally on the WDS Server itself.

Regardless of which you choose creating a boot image is the same:

1. Right click on boot images in the WDS Console
2. Choose "Add Boot Image"
3. Browse to the location of the .wim file you wish to use
4. Provide an Image Name and Description
5. Verify that everything is correct and click Finish

The winpe.wim from the WAIK lacks setup.exe and the supporting files that allow setup to function, but it does include everything needed to create a capture image.

The boot.wim from an OEM DVD is locked to only deploy from DVD, the file you are interested in is pid.txt which is used for filtering.

7. Creating a Capture Image

 To create a capture image you must have a boot image first. The capture image is based on the boot image available to the server. Once you have a working boot image, then creating a capture image is very straightforward:

1. Right click on the boot image
2. Choose "Create Capture Boot Image"
3. Provide an Image Name and Description
4. You must also provide a location to store the file
1. The default location is \RemoteInstall\boot\x86\Images
5. Clicking Next starts the capture image creation process

0720: Deploying XP Image via WIM

 

Steps:

1. Install Windows XP via any means
2. Install and configure applications
3. Create a WDSCapture image
4. PXE boot remote client
5. Choose the Capture Image
6. Specify a local drive/filename for the image
7. Specify the WDS Server and Image Group

Create WDSCapture Image:

1. Open WDS MMC on server
2. Right click on a valid boot image
   1. Some discussion/confusion on newsgroups that a WAIK boot image won’t allow an install/capture
3. Choose "Create a capture image"
4. Specify a name/location

Additional Notes:

The boot image that you create can be from an OEM copy of Vista, but if so you must removed the pid.txt file from inside the image. Alternatively if you have access to a regular distribution DVD, then you can use the boot.wim from there.

0720: Converting RIS to WDS

 

Overview:

There are several methods of converting an existing RIS Server to WDS but the easiest seems to be upgrading to Windows Server 2003 SP 2. If SP 2 is already installed all you need do is choose WDS from the Add Windows Components section of Add/Remove Programs.

Scenario:

Existing RIS Server needs to be converted to WDS, Windows Server 2003 installed with no service packs. Active Directory is installed and configured, RIS is authorized in AD, a DNS and DHCP server are available on the network.

Steps:

1. Download and install Windows Server 2003 SP 2
2. After reboot open the "Windows Deployment Services" MMC
3. Choose "Add Server" from the Action menu
4. Select your server
5. With your server selected choose, "Configure Server" from the Action menu
6. Select your remote installation directory
7. Choose the method to which WDS will respond to clients

0718: After Action Notes

 

Problems:

• All computers need to be configured to PXE boot
• Dell Precision 390 desktops need to have SATA configured for ATA operation in order for RIS to work
• Updated RIS images need to be modified to have the Broadcom 57xx driver
• RIS has a limitation on the master image machine, if the drive is larger than the drive on the destination computer the image won’t deploy even if there is enough room on the destination computer.

Thoughts:

• Planning for the future, Vista can only be deployed via WDS
• Convert RIS to WDS on Server 2003
• Compare Windows Server 2003 WDS with the Windows Deployment Role in Windows Server 2008
• Extract MAC addresses from all SOECS computers from ANSR
• Create a script to manage DHCP
• Bring DHCP online for deployment
• Bring DHCP offline after deployment

0717: Proof of Concept

 

Delay:

There was a delay of over two weeks while we waited for NTS to agree on a time to monitor the impact of a test deployment on the network at large.

Results:

I have no concrete numbers on how things went, but there were 13 machines in the test. The first machine started at 3:10pm and reached a logon prompt at 3:37pm. The image was a base install of Windows XP with Service Pack 2, the size of the image on the server is pretty small, but in the grand scheme the amount of overall data I don’t think is as important, as that will only impact the length of time.

One of the problems presented by Ghost in the past has been how it pushes the image out using broadcasts. Historically an average Ghost session would create an overwhelming amount of traffic on the network which would at times overwhelm switches and other attached network devices.

The test deployment peaked at 97mpbs over a 100mbps switched network, there were little to no broadcasts related to the deployment, not floods, and the switch CPU’s were not overloaded. All-in-All I would say that things seemed to go quite well and I think that RIS is a very favorable solution that is easy to setup, integrates well with our AD (for obvious reasons), and is friendly on the network.

For the curious:

The RIS server itself is a Dell Optiplex 745, the drive where the images are stored is a Maxtor OneTouch USB drive, connected to a Netgear 100mpbs switch, certainly not the optimal hardware, but good enough for a test run.

0701: Deployment Results

 

Results:

• Test computers both appear functional
• All Applications appear installed
• No errors reported in the System Log

Thoughts:

In my experience when a Windows DHCP Server is online clients will retrieve IP’s from it instead of ANSR. It was explained to me that ANSR takes a little bit longer than the Windows DHCP Service, and since DHCP is "first-come, first-served" clients will almost always get their IP from the Windows DHCP Service.

• Create a private network on the KU LAN
• Assign private IP addresses to DNS, DHCP, an AD Servers
• Create a private scope on DHCP
• Create reservations for each lab computer, to prevent regular client from getting a non-routable IP