This is a teaser for what is to come. I am working a post that will provide some expert information about deploying Office 2010 in a network environment. I expect that to be posted this week. For now, I am going to discuss some software installation best practices that I have found to be beneficial and implemented with my customers.
There are four major steps in software deployment in a networked environment.
Step 1: Know the installation options available for your software. Take the time to learn the deployment options. Visit the manufacturer's web site, read the support documentation, and even look in the included documentation with the software. Sometimes you can even run the setup application with a /? to get installation help. Make sure you have the tools or capabilities to deploy the application with the least amount of administrative effort. Many times all you need is a little ingenuity and the ability to write a script. If I just scared you, don't worry. Scripting is not as scary as it sounds. There's plenty of help out there to get you what you need so you don't have to re-invent the wheel.
Step 2: Know your targets. When deploying software it's not a good idea to just throw spaghetti against the wall and see what sticks. A piece of software can break another piece of software causing what I like to term as a CLM - Career Limiting Move. In a worst case scenario that type of approach could break a piece of software that would be required for the company to make money. If you bring down the company's ability to make money that is what I like to term as a CEM - Career Ending move. You need to find a way to install the software only to the computers that need it. You could use a script to look for a file that exists that would only exist on computers that need the software. If it's in a department of the company maybe there is an IP range involved. You could use the computer's IP address as an identifier. All of these things can be identified through scripts. Deployment tools make this process much easier. This gives you a way to identify your targets.
Step 3: Test your deployment. After you have identified your installation options and targets, create an installation package and install it to a test computer that mimics your targets. This method gives you an idea if the deployment goes as you expected. Look for errors, review logs, make sure the installed application is functional. If anything did not work as expected, review the cause, fix it, and redeploy it. Continue this process until it deploys the way you want it to.
Step 4: Pilot the deployment with a small group of production computers. Once it's ready, send it to a few of the production computers. Make sure it is still doing what you expected. If it not, go through the troubleshooting process. If so, deploy as you see fit within your environment.
I have used these steps as best practices for software deployment throughout my IT career since 1995. I have heard a lot of system administrators tell me they don't have time to work through these processes, because their bosses are wanting the software deployed as fast as possible. This process is not just a CYA process, but a business process, too. These steps reduce the risk to the business by reducing downtime due to failed application deployments. It makes your time more effectively used to be proactively managing your network. All of these efforts translate into bottom line improvements. I bet your boss will like to hear that information. Hopefully, this will help you be a more effective system administrator and provide more value to your career.
There are four major steps in software deployment in a networked environment.
Step 1: Know the installation options available for your software. Take the time to learn the deployment options. Visit the manufacturer's web site, read the support documentation, and even look in the included documentation with the software. Sometimes you can even run the setup application with a /? to get installation help. Make sure you have the tools or capabilities to deploy the application with the least amount of administrative effort. Many times all you need is a little ingenuity and the ability to write a script. If I just scared you, don't worry. Scripting is not as scary as it sounds. There's plenty of help out there to get you what you need so you don't have to re-invent the wheel.
Step 2: Know your targets. When deploying software it's not a good idea to just throw spaghetti against the wall and see what sticks. A piece of software can break another piece of software causing what I like to term as a CLM - Career Limiting Move. In a worst case scenario that type of approach could break a piece of software that would be required for the company to make money. If you bring down the company's ability to make money that is what I like to term as a CEM - Career Ending move. You need to find a way to install the software only to the computers that need it. You could use a script to look for a file that exists that would only exist on computers that need the software. If it's in a department of the company maybe there is an IP range involved. You could use the computer's IP address as an identifier. All of these things can be identified through scripts. Deployment tools make this process much easier. This gives you a way to identify your targets.
Step 3: Test your deployment. After you have identified your installation options and targets, create an installation package and install it to a test computer that mimics your targets. This method gives you an idea if the deployment goes as you expected. Look for errors, review logs, make sure the installed application is functional. If anything did not work as expected, review the cause, fix it, and redeploy it. Continue this process until it deploys the way you want it to.
Step 4: Pilot the deployment with a small group of production computers. Once it's ready, send it to a few of the production computers. Make sure it is still doing what you expected. If it not, go through the troubleshooting process. If so, deploy as you see fit within your environment.
I have used these steps as best practices for software deployment throughout my IT career since 1995. I have heard a lot of system administrators tell me they don't have time to work through these processes, because their bosses are wanting the software deployed as fast as possible. This process is not just a CYA process, but a business process, too. These steps reduce the risk to the business by reducing downtime due to failed application deployments. It makes your time more effectively used to be proactively managing your network. All of these efforts translate into bottom line improvements. I bet your boss will like to hear that information. Hopefully, this will help you be a more effective system administrator and provide more value to your career.
No comments:
Post a Comment