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. 

Application specific configuration information should be stored in web.config files, or in files specified by the web.config file. Common types of information that are stored in web.config files are:

·          Application wide error messages

·          Enabling/Disabling debugging

·          Application level tracing

·          Configuring session state

·          Custom settings (database information, connectors, etc)

This type of configuration data should be items that are common across the entire application and users. Updates to web.config should be minimized to prevent instability in production systems. It is noted that tracking of different versions on the web.config file will be necessary due to configuration changes between various development and production environments: alpha, beta, cert, prod.

There are two methods for maintaining user specific configuration information. One method is to store user specific information is web.config files. An alternative to this is to store user specific information in a database, and have it retrieved by the application at runtime. Both methods are supported. However, the recommended method is to store user data in a database.

Storing user information in web.config files is one method to store and retrieve configuration settings for users. There are inherent problems with this model however. From a support perspective, a new configuration file and release information must be updated every time a user is added, removed, or modified. The web.config file must also be replaced on all servers running the application. Updating several machines leads to the potential of a server not being at the same levels as those of other servers. In addition to this, on a loss of hardware, there is the potential that when a machine is rebuilt, it will not have the latest configuration files.

Utilizing a database for user data is the recommended method for storing user related configuration information. There are a number of benefits to managing configuration information within a database instead of utilizing xml configuration files. The primary benefit is in maintaining application and user integrity. By removing user information from the web.config file, upgrades and modifications can be made to the application without the possibility of omitting a users’s information, having a user’s information be configured with out of date configuration data, or data from another development region. Another benefit to a remote centralized repository is that a change made in one location can be automatically picked up by all applications in the cluster. This will ensure that all applications are using the same configuration information for various users.

So in the gist of getting the site up and running again, I decided that I once again wanted to start checking where traffic was coming to the site from. At this point, I would be surprised if there is any traffic coming to the site. Considering that the site now has a horrible color theme and, with this post, 3 whole entries, if anyone is coming to the site it is for laughs.

Traffic analysis. That is why am here today. There are a ton of stat programs out there, and my provider has one, and they all have their pluses and minuses. The one provided by my Web hosting provider was awstats. I have used this in the past, and while the information is not bad, it is not great. Currently, DiscountASP.net, my site hoster, said that they are changing web stats programs, and for the short term I would be without stats. I am fine with that, but in the meantime I still would like to know if there is any traffic coming to the site, and if so, where is it coming from. So this means installing Google Analytics. 

As a side note here. After the new stats package is installed, I will continue to use both for checking my traffic statistics. It is not that I do not trust Google or whatever the new package is, but I like to compare stats to ensure the honesty and integrity of the information. Hopefully the two programs will never be more that just a bit off from one another, but that will have to wait till later. If they are not, then I am not sure what I am going to do. Probably try and compare the two with the raw logs and see which one is really accurate.

Back to the main discussion, installing Google Analytics on BlogEngine. Installing Google Analytics is very simple, and can be broken down into a list of three steps.

1. Log into your BlogEngine site and go to the Settings page.
2. Log into Google Analytics and get the java script code for the page tracking.
3. On the Settings page in the section labeled "Tracking script" and paste the code into box.
4. Click on the "Save" button.

That's it. Guess that is 4 steps, but who's counting?

I do have questions about whether or not the code is added to the pages when you are logged in as an administrator. Until I have a chance to peak into the code I will not know. The advantage to this would be that the statistics on the site would not be thrown off by ones own visits. If the site is getting a large amount of traffic, I guess that this would really not be an issue. However, if your site is like mine, then just my traffic alone could make me happy. Ha.

Hmm. Guess that was anticlimactic. Sorry that this was a lame post on how to install analytics on BlogEngine, but who was I to know that it would be so easy. I have used other blogging software in the past, and it has always been amazingly difficult to setup analytic with these systems. I remember having to hack a number of PHP pages in WordPress to get it to work. There may have been an easier way the last time I set it up, but I cannot remember if there was a plug-in for it at that point. 

Just know that setting up Google Analytics is easy to setup and use with BlogEngine, and that it is a good tool for monitoring the traffic going to ones site. 

I am glad to say that the site is now being powered by BlogEngine.net. This is a dramatic change from the technology that this site used to be running on. If you were unable to tell by the name, BlogEngine is powered by dotNet. Previously all the sites that I had used had been powered by either PHP or Java. While both of these have programming languages have their pluses, I felt that it was time the .Net was given a chance.

It is true that there is a limited number of Open Source blogging software for the .Net framework. This is probably more due to the fact that most open source advocates learned PHP, perl, python, etc first. Also, most open source advocates would not be caught dead using Microsoft technology. Having been a long time user of Linux and Unix systems I can understand this veiwpoint. At the same time, I find it extremely limiting when people are unwilling to accept or at least try an alternative. Just because a company is out to make money does not mean they are evil. The argument could be made that Google is more scary with the amount of information that it has on people than Microsoft, but I digress.

Back to the original topic at hand, that of Blogengine.net themes. In that past, I have always grabbed a theme by someone else, and then tweaked it to meet my needs. I thought about doing this with BlogEngine. However, after looking at what it takes to make a theme, I believe that I am going to make one myself. To my surprise, unlike most php blogs that I have used in the past, there is a nice separation of code and html. Never know, I may continue on to work on some extensions.

Reality calls, time to take out the trash and fold laundry. Ah the pains of home life ;) Till later 

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.