Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.
Backup Exec

Backup Exec Install Blog (AD Installs of RAWS)

Created: 11 Jul 2011 • Updated: 28 May 2014 • 2 comments
Nick Elmer's picture
0 0 Votes
Login to vote

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,

Comments 2 CommentsJump to latest comment

MitchR's picture

First I'd like to recommend that you configure the GP object to deploy to a specific group, and not every computer in the AD tree. (Under Security Filtering, remove "Everyone" and add a "Install FooBar App v1.0" group. Add selected computers to that "install FooBat App" group.)  That gives you control in staging out new releases.

One issue that's a pain for GP deployment is the new "trust relationshop" security on deploying agents.  You have to go back and manually authorize all agents, which you don't have to do with a push.

As for dealing with patches, that's easy.  I can think of 3 different ways off the top of my head:
- Make a new package with the new version. Delete the old GPO object pointing to the old package.
- Edit the GPO of the old object. Delete the reference to the old MSI, then add the new one.
- On the GPO object, right-click on the MSI entry, All Tasks, Redeploy Application. 

Any one of those three should do the trick and will kick in at the next reboot, just like any other GP deployment.

One minor suggestion - next release, don't hide the MSI file 3 levels deep. Put it directly in RAWS32, RAWSX64, etc.

Mark this post as the solution, and have good luck for 7 years.
Forget to mark this as the solution, and tomorrow your server will crash.

Login to vote
Nick Elmer's picture

Hi Mitch,

If I understand your first comment, you are recommending to other users of GPO deployment to remove everyone and create a group that targets their deployments, and I agree with that. Will see about getting that content added to our documentation as well.

As far as trusting, we do not have a way to automate the trust of the agents when installing via GPO. When push installing, we have secure channels in place that allow the trust to be automated. I know of some work that may help automate this in a future relase, but it cannot be done today via GPO deployments. You will have to manually trust the agents before backup, but that will happen when you create the selection list anyways.

I need to revisit patch deployment via GPO, there may be some subtle changes we could make that would simplify the distribution of patches in this environment, and allow it to work with only a redeploy of the agent. Will try to get some time to investigate this.

Thanks for the suggestion on the folder depth. The folder structure is a carry over from previous releases. Our intent was not to hide it, but keep the MSI portion of our install separate from the dialog binaries. RAWS and BE installs are really two phases. 1. Collect settings, 2. Execute the install.

I appreciate your comments!

Login to vote