How the State of Ohio's Department of Taxation is using SVS

I work for the Ohio Department of Taxation and this is a glimpse into our implementation of Altiris' Software Virtualization Solution. We have been implementing Altiris' Total Management Suite (TMS) over the last two years. We started very slowly at first, but the last year has been an absolute blur. Overall, our TMS implementation has been a resounding success.

We have been using SVS since we began designing our Altiris infrastructure. I pushed early on to ensure that SVS would be our stated direction for software packages on our workstations. I could see the vast benefits that this methodology would hopefully bring for us versus the old fashioned deployment methods.

We currently have around 100 SVS layers packaged, tested and approved for deployment, with more in the works. Our standard workstation image contains up to 15 SVS layers, depending on the hardware. The vast majority of our add-on applications are also SVS layers.

We have recently implemented Asset Management and are finalizing the ties between things to enable deployment of software automatically.

Basically, we have authorized and unauthorized collections for all of our SVS layers.

Click to view.

This is just a partial listing of the collections. Here is a peek at the guts of the collections:

Click to view.

Click to view.

When someone needs an application, a Customer Service Request (in-house workflow app) is submitted by the user. This is automatically turned into an Altiris Helpdesk Incident. The incident is routed to the appropriate member of the Asset team to determine if there is a license available, and that this user should consume one of those licenses. Once everything is OK'd, the user's computer is added to the authorized collection and the incident is resolved. By design, the workstation is automatically removed from the unauthorized collection when placed in the corresponding authorized collection. Within the next hour, the application will be delivered to the target workstation from that system's appropriate local package server.

If the software is no longer needed on that system, or the wrong system was added to the collection, simply removing the computer from that collection will cause the SVS layer to be removed from that system within an hour, because removing the computer from the authorized collection automatically adds it back in the appropriate unauthorized collection.

Automated Software Delivery

We are in the process of finalizing the design of some of the more complex automated software deliveries. We have a couple apps that require multiple layers to be imported and activated, while at the same time other layers that were there by default will need to be disabled. These will work in the same general way as the others, as far as automated delivery is concerned, and when removed from the collection, the system is taken back to the original set of layers.

If the user needs the software now, and can't wait for up to an hour, we have a DS job that forces an NS Update Configuration to happen, to let the system grab the software right now. We are also finishing up the creation of corresponding DS jobs for every SVS layer, so we have multiple delivery methods available.

Deploying software to our workstations is truly that simple, and managing it just as easy. Our users don't even need to be physically attached to our network. We support deploying NS tasks through our VPN connections so our end users can receive their applications (and patches) from anywhere.

Now that we are in the wrapping up stages of our Altiris TMS implementation, things are working really well, and we have been able to provide services to our end users in a significantly faster and more reliable method than we have ever been able to in the past. We have been able to do a good job in the past with other deployment tools, but Altiris TMS has truly revolutionized our workstation management capabilities.

Enterprise Upgrade

We are currently in the process of an XP upgrade for the entire enterprise. We have decided that the most efficient way to do this is to just swap the user's computers out. This means that someone needs to go through and remove the old computer from the authorized collections and add the new one to the same authorized collections, otherwise, when the original system is redeployed, there may be some software that is automatically delivered that shouldn't be. This would end up being a lot of time consuming work for someone.

To get some help with this, I asked the Juice community for assistance, and Screenbert jumped at the chance to help me out, and yes, the bounty offered probably helped a lot. He took my request for a tool that would automatically take care of this manual task and automated the vast majority of the process. He created the Automated Collection Subscription Tool (ACST) and released it on Juice. At some point, this tool will be able to create an Altiris Incident for each of the systems that were changed to show the change history of those assets.

You can find the tool at: www.symantec.com/connect/node/1557

Now the Asset worker has a simple tool to use. Simply enter the old and new computer names and hit the "get collections" button. From there collections with "authorized" in the title (keyword can be easily changed) are listed for both computers. Highlight the collection and click the "go" button and the old computer is removed from those collections and the new one is added to them. This is fantastically painless; many thanks to Screenbert for creating the tool, and my thanks also go to the Juice administrators for offering the bounty on the tool.

Here are a couple screenshots of the tool:

Click to view.

Click to view.

Bumps Along the Way

We have done some fantastic things, but it hasn't always been a rosy picture. We did run into some unexpected problems with SVS in the beginning. The biggest problem that we had was assuming that the exclusions were being built properly. We didn't realize the problems until after we had deployed new systems with full SVS support to around 50 users.

We use Lotus Notes as our email client. We used the excludegen and excludecopy tools to look at the layer and build all of the exclusions for us. One of the things that we didn't take into account was the fact that you can email someone anything, with any extension, including made up ones.

On our initial production deployment of our new image with SVS, Office 2003 was in a layer as well. Some end users were ending up with multiple copies of the same files, some stored in layers and some in the base, and it was causing much grief.

Basically, the user would receive a spreadsheet via Notes and save it. Since we didn't build in exclusions for .xls extensions for this layer, the files were stored in the Notes layer. Next, the user would open the file, and edit it with Excel, and save the file. Since the file was modified with Microsoft Excel, and the .xls exclusions were built into the Office 2003 layer, the file was dropped into the base. Now the user received an updated file from the original sender, and they saved the file. The user was prompted to overwrite the file, and they did, but when they opened it, the file was still the original since the new one was in the Notes layer. This was a very confusing problem, especially for our end users.

The solution to this problem won't be implemented for a while in our environment. Basically we would need to use Data layers to resolve this problem. I am not positive as to what all is actually going to be involved with this, but it sounds pretty simple. I haven't looked into it much because we have to fix a larger problem first. Our end users can save data anywhere the OS will let them. The have been instructed to save files in a specific folder, and all standard apps (word, excel, etc) have been modified to default to this location, but user's can change these settings, and there hasn't been a change in policy yet to force them into compliance. Since the user's can save data anywhere, there are some apps that we simply can't use in SVS at this time. We are working to fix this.

Looking Ahead

If the [v2.1] code is as solid as I am hoping that it is, we will begin moving the apps back into layers. During the next revision of our image, we won't have near as many forest fires to put out (hopefully), just the normal daily stuff, so we should be able to devote more time and energy to getting SVS working exactly how we want it to in our environment. We have been able to do a huge amount of things with SVS, and we are planning on a lot more over time.

Basically, we grabbed this bull by the horns and we got knocked off a couple times, but we kept dusting ourselves off and we are riding again, only this time we have a pretty firm grip.