I know there are 9,342 entries out there on how to sysprep a server. In fact I thought about not bothering writing this up at all, but figured that at some point in the future I would once again need this information. Also, I am setting up this image for use with Automated Deployment Services (ADS). I am moving on to SCCM for operation system deployment, but a new build is needed now. It is not an overly complicated procedure. So you understand the layout of this post, I am going to number the major points, and then add comments to them as I move forward.

For starter, what is sysprep? Sysprep is a tool from Microsoft that is for use in cloning or creating new servers. Once a server has been syspreped it can be used with various deployment tools. These can be non-microsoft or Microsoft tools. Another reason to sysprep a machine is to provide a clean image will all the software that is part of a base or clean image. I leave more research on what Sysprep is to you. Let's get started with this information:

1. Build a server and install whatever software that you want on it. (I like to keep my clean, and add packages later)
2. Insert the CD/DVD that you built the server from and copy I386 to c:\WINDOWS\
   1. Note: This is done to make life easier when installing packages or adding features to the machine that is being built. It is a pain to have to put in a network path or find a installation CD/DVD everytim you need to add a component to a server
3. Create the sysprep directory on the base of the C drive
   1. Open Start -> Run -> Type 'cmd'  
   2. C:\>mkdir c:\sysprep
4. On the installation CD open the CAB file that has sysprep in it and copy files to c:\sysprep
   1. Locate DEPLOY.CAB on the installation media. Should be something like D:\SUPPORT\TOOLS\DEPLOY.CAB
   2. Double click to expand the CAB file.
   3. Copy setupcl.exe, setupmgr, and sysprep.exe to c:\sysprep
5. Enable Remote Desktop Connections (RDP). Only do this if you want to be able to term serv into your server remotely. Highly Recommended.
6. Run ADS agent installer. (not going into detail here as ADS is another issue altogether)
7. Run sysprep. This is what we have been waiting for.
   1. Note: I am using ADS so I am not interested in create a sysprep.ini file with answer information. James Kovac has a page that discusses this.
      
   2. Open up the command line.
   3. Run sysprep with the following flags -reseal and -reboot. This machine is going to boot into the deployment agent so shutdown is not needed. If you were going to use this image on other machines you would need a method of copying the disk. I leave this up to you.
   4. Run 'c:\sysprep.exe -reseal -reboot'
      
8. Call it a day.

Hopefully this will help someone out there. I know that this is not a comprehensive breakdown into sysprep, but hopefully I will be moving away from it as I move onto SCCM. The deployment features in SCCM are much better than using ADS. Next time a hardware update is done, I should only have to insert some drivers into my WinPE image and to the build process.

One can hope.

Let me start by saying that I have worked on both the Unix/Linux and Microsoft sides of the house. That being said, I can argue the positives and negatives of both platforms. That is not the point of this post. The point is that being able to automote tasks is a primary aim of system administration and engineering.

For me, Perl has always been my language of choice when it comes to scripting languages. Now there are some that will say the Perl is a full blown programming language, but for me it will always be a scripting language. When I first started using Perl, it was for Linux/Unix systems only. At the time I was primarily doing Linux admin work so it was to be expected. About a year after beginning to do scripting using Perl, I had the need to script out some stuff for some windows systems. Instead of learning vbscript, which only works on windows, I used Perl. Perl had the necessary modules, and worked on both sides.

Jump to 2006. Microsoft releases Powershell.To be hones, I did not use or pay much attention to Powershell. It has not been until the last 6 months that I have given any credence to Powershell. Powershell does take a different look at the shell in that everything is an object. This is a blessing and a curse all at the same time. For today's discussion it is beyond the scope. (Got that line from college) 

This brings me back to the topic at hand. How well does Powershell work for scripting? My view is that it does not quite make the mark yet. Powershell has the fixings to be a great scripting language, but I do not think it is quite there yet. The best comparison that I can make is that Powershell is a great SHELL, but not quite a scripting language yet. Part of that just might be that the wrong people have been writing books and documentation for it. I am doing more research, but as of yet I am still not convinced.

One of the things that I think is a failure of Powershell is file handles. In Perl you can create a file handle for reading, writing, both. In powershell you have to break into the .Net library to do that. This takes Powershell out of the scripting realm for me. 

For now I still feel that Perl is the best scripting language, but that Powershell has all the shells beat. 

Up and running. SQL backend, with some stuff local. Feeling good about it.

 Now I just have to tweak the look and feel, and start adding content.

One thing at a time though.