Backup Exec Install Blog (AD Installs of RAWS)

[Nick_Elmer]

Hello again!

Many of you probably do not know that I started in support some 15+ years ago. I spent a number of years helping customers with various technical problems. It is because of those years I spent in support, I learned a lot about customer experience and expectations. It gave me a real appreciation for the problems our customers face. Now as I work on product features as a developer, I am always looking for ways to improve what we do for you! When I work on a feature, I want to make the functionality obvious, simple, and if possible, 100% reliable. I realize that’s not reality, but that is always my goal!

One of the features I was responsible for a few releases back, is the Active Directory(AD) install of RAWS via Group Policy Objects(GPO). For those who do not know what it is, it is a way to add an application to Active Directory, that is installed on demand or on system boot. We choose a per computer approach since RAWS is installed per machine, and not per user. To use the feature, you run the RAWS install on a computer, and choose the “Create transform option”. You make the selections you wish to use like install directory, advertised machine, and transform name. This will create a .mst file for use by AD. You then copy the RAWS install files to a public network share and drop the transform in as well. Once that is ready, you then go to AD and edit your desired GPO. Within the GPO is an per computer, software deployment policy. Within that, you add the RAWS package by browsing to the share. You then specify a transform to use. This transform gets applied to the MSI when it runs, and defines which options will get installed on the computers within the specified Organizational Unit(OU). Once your settings are finalized, and saved, things will start to happen. When a machine comes up in that OU, AD will launch an install of RAWS on the system via the network share, using the specified transform. Once the install completes, the system knows if a reboot is required, and will automatically shut down and restart the system prior to user login. Should a user remove the application, it will be reinstalled on the next reboot. If you move the computer to another OU, it will automatically be removed (if you select the option to uninstall the application when it falls out of scope). Again, if a reboot is required, the system will automatically restart prior to user login. In addition, GPO’s allow upgrades from one version to another. See the Backup Exec Admin Guide for more details.

When we implemented this feature, I believed that it would allow many of our customers with large scale environments to deploy RAWS easily to their domain members. Now that it is long since done, I believe we achieved the goal. However, it seems like there are only a handful of customers using it. I’m not sure I understand all of the reasons why our customers are not using it more, but I have some ideas. One reason I would not use it, is because it doesn’t have patching support built into the deployment model. Microsoft did a great job of deploying applications via the tool, but patching was omitted from the GPO implementation for some reason. That means the vendor has to build patch support into the application being delivered. It is a major concern for any customer deploying RAWS through this tool. Instead, I believe that many of our customers prefer to use our push install. Since our push install is one of the only ways to deploy updates to all of your RAWS, it is probably the preferred method for many of our customers. Not to mention it is the easiest to use.

I would be interested to hear from those who are using the AD GPO deployment feature of RAWS, AND those who are NOT using it for all the various reasons. If you have suggestions on how it could be improved to make it more attractive, I’ll move your comments to the top of my list. J I also added a poll for those who do not wish to comment, but would like to submit their vote.

Thanks for reading,
Nick