(Warning, the contents of this article are opinions of the author, who does not pull punches nor keep a lid on his opinions. He offends many and apologizes to few. You have been warned)
And here comes 2006, wow how time flies. It seems like only yesterday I was at my first job in the IT industry migrating from a Novell / Windows For Workgroups 3.11 environment to a pure Windows NT 3.5 environment. Which is a great segue to my rant of the month…
Does your infrastructure contain:
1. Systems configured as members of a Workgroup?
2. Any Operating System based on the Windows 9x kernel?
3. Desktop, laptop or server systems not enrolled in an automated Patch Management solution?
If you answered yes to any of the above questions, send me your hat size. I’m filling out an order form for dunce caps and they’re not one size fits all.
Seriously folks, as stated above, the year 2006 is just around the corner. Unfortunately we have all graduated from the days of separate islands of account security, lack of robust Operating System code and the ability to wait until the application of a Service Pack in order to apply pending security hotfixes. The bad guys are out there, don’t kid yourself. What’s that? No one has ever broken through your firewall and compromised any data? Congratulations. The only thing worse than being vulnerable is living under the false assumption that you are impervious to breaches of security.
I once worked for a CIO who didn’t want to migrate to Microsoft Exchange because the outdated and proprietary email system that we used rendered us “safe from any incoming email viruses” since in his mind, all viruses sent via email only did so via Exchange. While it is a very true statement that a majority of email based viruses capitalize on functions specific to the Exchange environment (due specifically to the sheer number of Exchange mail users), this kind of blanket statement made me shudder with fear as I knew it would be a tough battle in order to procure any investments in security software and tools. Needless to say, in addition to some of the small virus infections that permeated the environment from time to time, I recently heard of a full scale assault that plagued the network. Unfortunately, I also learned that this same proprietary system was in place and not configured any differently than in years past. Those who do not learn from history…
I won’t bore you with the same old facts and figures that get thrown around from every vendor and marketing agency on the planet. Instead you, lucky reader, get full and unfettered access to my opinions on the following subjects:
1. Systems configured as members of a Workgroup – Not only is this 10 year old technology, but it is the lowest and most insecure form of networking. Accounts and passwords are stored locally, must be duplicated on each system, and it is technically scalable to no more than 10 systems. Typically, these types of “networks” are created by development or engineering teams that manage their own hardware (either by budget or resources). Unfortunately, what is also typical is that the systems are configured with FAT partitions (open and unencrypted hard drive contents) and the accounts and passwords are often shared among many team members. There are too many ways available to create a central secure repository of accounts for you to have this configuration in your network. Microsoft and Novell both have several products available, as well as many free solutions from Open Source vendors. Look into it. Now. If you don’t know where to start, email me directly and I’ll offer some suggestions.
2. Operating Systems based on the 9x kernel – If this applies to you, let me warn you now, I don’t have anything nice to say to you. If you are easily offended, then quit reading this and upgrade your systems. Now.
OK, so perhaps you missed my first references to the year 2006. Go back and read it again. Now that we have established the year, let’s do some quick math…
Windows 95: 2006-1995=11 years
Windows 98: 2006-1998=8 years
Windows ME: 2006-2001=5 years
Folks, these are home Operating Systems, designed for people like my grandparents to send and receive emails with pictures of their latest trip they took to see Yellowstone. You can run your business on this platform, however if you do, please tell me ahead of time so that I never, ever, ever give you any personal or financial information because I don’t trust your network.
You’ll notice the lack of any recommendations here. If you need a recommendation for this section, there is only one. Update your resume because you’re sitting on a ticking time bomb.
3. Desktop, laptop or server systems not enrolled in an automated Patch Management solution – Time for me to open up. I used to religiously wait for Service Packs in order to install security fixes. I never had the time, and I certainly didn’t have the patience to test applications that would inevitably break because I applied these patches that even Microsoft admits “are not fully regression tested”.
Remember 2003? Remember MS Blaster? What a wakeup call. So I’m on the phone at 3AM with several Executive members of an extremely large global company nearly 32 hours into what would turn into a 46 hour day, hearing more F-bombs come through the speakerphone than I ever heard my truck driving father utter in my entire life, when I realized that the practice of Service Pack-only applications of hotfixes may not be the most intelligent way of keeping systems up-to-date and secure.
You see, when you can render tens of thousands of computer systems inoperable because no one thought it was important enough to allocate funds to Patch Management, even Executives begin to understand how important it is. As I said before, the bad guys are out there, they want in, and they know of more ways to do it than you know of ways to stop it. Ignoring the problem will not make it go away. It is a sad fact that we in the industry are in the position of frantically applying patches and then holding our breaths hoping that the effort was good enough to keep the wolves at bay for this month. However, as sad as it is, it is the world we live in. I don’t like it and you don’t like it. Your boss, your boss’ boss, your boss’ boss’ boss, and every customer that your company has doesn’t care that we don’t like it. It’s our job.
Let me say that again. It’s our job. If you don’t “feel like it today” or you “don’t have time” to get to it, then get a new job. We have a responsibility to our companies and our customers to secure our networks, and consequently the Internet. If you leave your network vulnerable, then the same Internet that I try to conduct business on becomes burdened with compromised “zombie” machines owned by “Crackers” that allow them to continue the cycle. Don’t interrupt my ability to conduct business and I promise I won’t interrupt yours. That said, you have an opportunity to make great strides and show tremendous value. Bring your IT environment to the next level of operational efficiency and an increased state of information security.
Return to Top
IT organizations have 3 new issues that have dramatically increased the size and complexity of their Exchange environments. These three issues are as follows – regulatory compliance such as the Sarbanes-Oxley act, an increased use of Exchange as a file storage medium by normal users, and unmanaged .pst files. All of these issues can add Gigabytes, if not Terabytes of data to an existing Exchange system, something that Exchange was never intended to be used for.
The Enterprise Vault application by Symantec is a solution to extract this data out of the Exchange environment and move it to a more manageable solution on a traditional file server/SAN device. The Enterprise Vault solution moves all the messages that you select to archive off of the Exchange database and stores them as flat files on the designated file server/SAN device then, the application puts a placeholder in the user’s mailbox that points back to its message on said file server/SAN device. When a user clicks the placeholder, the message in its entirety is retrieved and the user is able to view the message, including attachments. This application will also tie in with the journaling feature for Exchange and archive all messages that have been saved via the journaling process. This keeps down the maintenance and size of the journaling mailbox, which would routinely fill up due to volume of copies of messages it processes.
The install process of Enterprise Vault is fairly simple, but it does require access to a SQL database, and its own license for SQL 2000. SQL 2000 is used to hold all the configuration parameters within your Enterprise Vault environment. After the install, one needs to do a bit of configuration for the archival process. The archiving can be done at date (so you could do it weekly, monthly, or even yearly) and can be configured down to the organizational unit level of Active Directory. So users in Accounting and Marketing who have large Excel spreadsheets and PowerPoint presentations could be archived more often than regular users.
The second feature specifically tied to with Exchange is the PST management feature. This lets an IT department take control over unmanaged .pst files that are located on users desktops or file shares. Basically the product will go out and search an entire network and find .pst files and move them to a central location in a flat file format. Then (like the archive solution) the product will place another placeholder in the users mailbox that points back to the original message. This solution helps protect the IT department from accidental deletions and or software/hardware failure on a user’s laptop/file share.
One last feature that really stands out about the Enterprise Vault product is the effect it has on the time it takes for Exchange migrations from one environment to another. A great example is for an Exchange 5.5 to 2003 migration. After the initial setup of the Active Directory Connector and Exchange 2003, the next major hurdle in a migration is the actual physical migration of a large number of mailboxes averaging many MB’s in size to the new platform. If you combine the archiving and .pst management functions of the Enterprise Vault product with your existing Exchange migration strategy, you can significantly reduce the time it takes to do the physical migration of the mailboxes. Instead of migrating 1000 mailboxes at 100 MB’s each, you could just be migrating 1000 mailboxes with 5 MB’s of placeholders instead. This significantly reduces the amount of time it would take for the actual migration process because you would be actually only migrating 5% of the data instead of the entire 1 TB of data those 1000 mailboxes at 100MB’s each would be.
As I mentioned before, Exchange was never designed to be a replacement for a file system, but in recent years it has definitely become commonplace for users to store their large attachments within their mailbox. Enterprise Vault offers a great solution for not only reducing this amount of data within the Exchange environment, but also as a regulatory tool for new legislation like Sarbanes-Oxley and as an accessory for Exchange migrations.
Microsoft Windows XP Professional can be deployed within your organization in many different ways. This article will discuss the cream of the crop, Sysprep. Sysprep is not an all in one deployment utility. Rather, it is a complement to many of the popular disk cloning utilities, such as Symantec's Norton Ghost. Sysprep allows you to customize your -golden- image to be used in your enterprise, and then clone it to all of your workstations.
This paper is not intended to be a guide to the best practices of configuring Windows XP Professional. This paper will cover how best to utilize Sysprep and a third party cloning utility to allow you to deploy a standard image throughout your organization. This image will be configured to reduce the amount of input by deployment personnel to a bare minimum. In fact, the image detailed in the following scenario requires only the machine name to be successfully deployed. By cloning your base image, you can minimize your departments support costs by eliminating workstation -deltas- (one machine configured differently than others) and the possibility of human error during the setup process.
What is Sysprep?
Sysprep is a utility that will allow you to duplicate a fully configured Windows XP installation to a large number of machines. This utility automatically regenerates the SID on each duplicated system. Sysprep can also be used to duplicate stand alone and member servers. At this time, Sysprep cannot be used to clone Domain Controllers. You can however create a base server image, and then run DC Promo on each server to reduce deployment time for a large number of similar servers. Microsoft has written a very informative Whitepaper on the subject called Automating Windows XP Deployments with Sysprep located here.
The version of Sysprep that comes on the Windows XP CD has been updated to V 1.1. You can download the new version here. This new version eliminates the mass storage controller dependency of the original version. Previously you would need to create a separate image for each system that had a different mass storage controller. Sysprep is still dependent on the Hardware Abstraction Layer, and you will need a separate image for each variation of HAL's within your enterprise. When used in conjunction with Plug and Play, you can deploy Windows XP Professional throughout an entire organization with one single image.
Using Sysprep
The following is a brief overview of the Sysprep process:
1. Install and configure Windows XP Professional.
2.
Install and configure applications.
3.
Run sysprep.exe and shutdown computer. (note: sysprep.exe uses options configured in sysprep.inf)
4.
Clone image to network share utilizing third party disk copying software.
5.
Deploy image to target workstation.
6.
On restart, machine with duplicated image parses sysprep.inf and runs minisetup.
7.
After minisetup completes, restart machine, SID is automatically regenerated.
Goals
The following is a list of requirements and goals that we will accomplish with this Sysprep image:
1. Reduce the amount of user/administrative input during setup of the machine.
2.
Give each imaged machine a unique name consistent with our organizations naming convention.
3.
Set the administrative password with setup. (In some organizations, tech support personnel are not given the local administrative password. This eliminates the only common account in use in an organization. We will set the same option here.)
4.
Allow additional applications to be installed after setup.
5.
Allow additional files to be copied to the workstation after setup.
Network preparation
For the purposes of this discussion, we will be deploying Windows XP Professional to our company named Trake Inc. Our main file server's name is DC1, containing our distribution share DIST$. We have created our Sysprep directory on our distribution share under the Windows XP directory. We will also need to create a directory named POSTPROC to handle some of our workarounds that we will incorporate into our sysprep image.
Sysprep components
The Sysprep directory will contain the following:
Sysprep.exe
Setupcl.exe
Pnpids.exe
Sysprep.inf
I386 directory - contains $OEM$ directory and cmdlines.txt
Sysprep.inf
Sysprep.inf is the configuration file that is applied to your cloned image for use with Minisetup. In keeping with our “minimal input” theme, I will highlight the main options needed to appropriately answer the most common setup questions:
[unattended]
ExtendOemPartition=1 (automatically extends system partition to size of disk)
OemSkipEula=Yes (End user license agreement acceptance)
InstallFilesPath = "c:\sysprep\i386"
[guiunattended]
timezone=015 (current time zone, refer here for complete listing of timezones)
OEMSkipWelcome=1 (Skip welcome screen)
OEMSkipRegional=1 (Skip Regional options screen - default US English)
[userdata]
fullname="Any Employee"
Orgname="Trake Inc."
[networking]
[identification]
DomainAdmin="trake\xpadmin" (Domain\username of account with permission to add computer account to domain)
DomainAdminPassword=123456 (Password of above account, please make your password stronger)
JoinDomain="trake" (Domain to join)
We are agreeing to the License and welcome screens by default.
External command processing
The $OEM$ directory contains a file named cmdlines.txt, which allows you to specify additional commands to run at the conclusion of minisetup. The standard method of utilizing this file is to script your additional commands here. After minisetup runs, the commands will be processed and applied to the machine. This would allow you specify the installation of extra applications and the like. However, if one of those applications becomes outdated, you will need to recreate your image just to remove the line that specifies the out of date application. This is where we will create another one of our own workarounds.
We will have cmdlines.txt invoke a batch file in the same local directory, which invokes another batch file on our network share to allow dynamic updating of these commands, again with no updating of the original image.
Here are the contents of cmdlines.txt:
[Commands]
".\cmdlines.bat"
The contents of cmdlines.bat:
@echo OFF
net use m: \\dc1\dist$ 123456 /USER:trake\xpadmin /PERSISTENT:NO
m:
cd windowsXP\postproc
postproc.bat
And finally the contents of postproc.bat:
@echo OFF
call adminpw.bat
regedit /s logonopt.reg
regedit /s legal.reg
copy logoff.exe c:\winnt /y
copy con2prt.exe c:\winnt /y
copy printers.bat c:\winnt /y
Your configuration of postproc.bat may differ. Here is what the sample postproc.bat does:
1. call adminpw.bat - This batch file contains the standard NET USER command to reset the admin password. This prevents us from having to specify it during setup, and allows us to change the local admin password on newly imaged machines if the original is ever compromised. This is useful if your organization has a policy of changing the local password every 6 months or so.
2. regedit /s logonopt.reg - Registry hack to blank out the Username field, and prepopulate the Domain field in the Ctrl+Alt+Del dialog box after your target machine restarts.
3. regedit /s legal.reg - Registry hack to create the LegalNoticeCaption and LegalNoticeText option. It may be a good idea to be able to change your Legal Notice on your workstations with the vast number of companies involved in mergers these days.
4. copy logoff.exe c:\winnt /y - A Resource Kit utility that allows you to remotely logoff a user from the workstation. Some companies do not currently utilize this utility, but it is there if ever needed.
5. copy con2prt.exe c:\winnt /y - A utility that allows you to script the installation of network printers.
6. copy printers.bat c:\winnt /y - The actual batch file for the network printer utility. Users simply select Start | Run | printers and all the network printers are mapped.
This is just a sampling of the many different configurations you can apply to your image dynamically. You can also add unattended installations of applications to your image to keep up with the ever changing world of software upgrades.
Using Sysprep in the real world
Now that we now how it works, let's make it work. We are assuming that you have created your master Windows XP image, configured all of your applications, and are ready to stamp this image as the Master. We also assume that you possess a third party imaging utility and have it configured per the manufacturers instructions for use in a networked environment.
1. Copy the Sysprep directory from the network share to the C: drive of the workstation.
2. Reset the local Administrator password to blank (not the word blank, just nothing)
3. Remove the workstation from the domain and put it into a workgroup.
4. After restarting, log in as the local Administrator with the blank password.
5. Remove all of your domain specific profiles from C:\Documents and Settings (we don't need to deploy extra profiles do we?).
6. Select Start | Run | C:\sysprep\sysprep.exe –mini -reseal (This will invoke a full plug and play scan during deployment to the new workstations to pick up any different hardware than what was used for this image).
7. The workstation will shut down (Well, it “might” shut down. Depending upon your hardware, Sysprep has a tendency to possibly hang and not shut the machine down. There have been various hotfixed for this bug, but I haven't ever gotten around to applying it. If you get the chance, go for it. Otherwise, just wait 20 seconds after the screen goes blank and then turn the machine off).
8. Insert your network boot disk to connect to the imaging share and use a third party utility to copy the image to the network.
That's it. You can use your third party imaging utility to copy this image to your workstations for deployment.
In our example, the only information that will be needed will be the workstation name. I have experimented with the approved ways of automating the naming of the workstations but never found a scenario that was able to take advantage of it. If your organization is willing to accept the default machine names given by Windows XP setup (cryptic at best), you will have a fully automated installation with absolutely no input by support personnel.
You will notice when you are prompted for the machine name that you are also prompted for the local Administrator password. Remember, we set the local Administrator password with postproc.bat, and any password you put in at this stage, will get overwritten with our after-setup processing. This is by design.
You can also reduce the size of your image stored on the network by deleting pagefile.sys, and hiberfil.sys (if applicable).
Summary
By utilizing Sysprep and a third party disk cloning utility, you can deploy Windows XP Professional to your network with the same exact configurations every time. With the utilization of Plug and Play in the Windows XP platform and depending on the variation of hardware in your workstations, you may be able to perform a full scale deployment to your organization with one single image.
You can also use this repeatability to your advantage with workstation support. In my neck of the woods, we troubleshoot for 10 minutes, then we blast down the master image to the workstation again. Returning the users workstation to a known, supported, working state. With the availability of free software for download from the Internet, and how that free software always seems to destroy something on an NT based workstation, this is a must for large scale shops. Otherwise the majority of your IT Departments time is spent troubleshooting problems caused by unsupported software.
Please take the time to read through the Microsoft Whitepapers regarding Sysprep and Automated Deployments. With a little planning, you can reduce the costs associated with supporting an Enterprise network tremendously.