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.