Installing Software with GP Best Practices?
Hi,
At my company we have recently migrated all our offices in to one big domain. I'm now looking for the best way to deploy software to all the computers in this domain at multiple sites, like DNA software we use to collect inventory info. Now, I think I've got the first step cracked in that I've set-up a DFS namespace to act as a distribution point in each office and this works great in testing.
I'm now not sure about the best practice in deploying software with group policy in large organisations.
Even some of the books I've looked at seem to be quite vague in that area. They talk about how to deploy software but don't really talk about best practice.
So far I can think of the following ways to do it...
Method 1. Create 1 Software GP and add 5 programs to this. Apply this GP to each office location OU eg. SoftwareGP.
Benefits: One GP. Less work to setup. In some ways easier to control.
Potential Problems: If you want to add another program to this later on, you don't necessarily want to install it to everywhere at once (risky?).
Method 2. Create a separate Software GP for each office location and add the same 5 programs to these eg. SoftwareSwindonGP. Apply individual GPs to the corresponding office location OUs.
Benefits: Can make changes to individual office software GPs and can add new programs in a staged process without effecting other offices.
Potential Problems: More GPs. A bit more work to set-up and with more GPs more things to manage.
Method 3. Create 1 Software GP for each program and apply this to each office location OU eg. SoftwareFlash9GP.
Benefits: Making 1 GP for each program allows you to stage the install by applying it at individual office OUs when you're ready to. So no issue with introducing new programs later on.
Potential Problems: However, what if you need to re-install it or upgrade it once its been applied everywhere. Again, you don't necessarily want to install it to everywhere at once (risky?).
Method 4. Create 1 Software GP for each program for each office eg. SoftwareFlash9SwindonGP.
Benefits: Can install programs in a staged way and can re-deploy, uninstall programs in a staged way.
Potential Problems: A Lot more GPs. Potential for mistakes.
This is what I can think of. There might be some other methods like setting up Groups and using GP permissions to control where its applied. If anyone has had experience with this, I'd be interested to know what you opted for. Or does everyone tend to use SMS or something in large organisations?
Cheers for reading this. I'd be interested in your thoughts.
Cellardoor
At my company we have recently migrated all our offices in to one big domain. I'm now looking for the best way to deploy software to all the computers in this domain at multiple sites, like DNA software we use to collect inventory info. Now, I think I've got the first step cracked in that I've set-up a DFS namespace to act as a distribution point in each office and this works great in testing.
I'm now not sure about the best practice in deploying software with group policy in large organisations.
Even some of the books I've looked at seem to be quite vague in that area. They talk about how to deploy software but don't really talk about best practice.
So far I can think of the following ways to do it...
Method 1. Create 1 Software GP and add 5 programs to this. Apply this GP to each office location OU eg. SoftwareGP.
Method 2. Create a separate Software GP for each office location and add the same 5 programs to these eg. SoftwareSwindonGP. Apply individual GPs to the corresponding office location OUs.
Method 3. Create 1 Software GP for each program and apply this to each office location OU eg. SoftwareFlash9GP.
Method 4. Create 1 Software GP for each program for each office eg. SoftwareFlash9SwindonGP.
This is what I can think of. There might be some other methods like setting up Groups and using GP permissions to control where its applied. If anyone has had experience with this, I'd be interested to know what you opted for. Or does everyone tend to use SMS or something in large organisations?
Cheers for reading this. I'd be interested in your thoughts.
Cellardoor
0 Comments
[ + ] Show comments
Answers (11)
Please log in to answer
Posted by:
revizor
16 years ago
There's going to be enough proponents of each of scenarios you listed - you can even run a poll :-)
What worked for us great in the past (environment w ~1000 PCs, 10 sites) for Software Distribution was a single policy with all the software going through it via ACL. There were security groups set up for individual software items (even versions, if necessary), as well as department suites (e.g. Marketing gets Adobe Photoshop + Quark + etc...)
Currently the policy contains over 200 items, and there seems to be no noticeable performance hit during bootup process.
Recently we became part of a larger corporation (35000 PCs, and 70-some sites). Their philosophy was different from ours, and they seemed to be torn between Method 2 and Method 3. It is pretty dismal - 700 policies, most of them are either empty, or test, or not even applied. Not that I am implying that taking either of those routes guarantees you a fiasco, but maintaining a large number of "smaller" policies does become an overwhelming task unless someone enforces discipline and proper control of GPO lifecycle. Little easier if you have a formal Change Control process.
As far as Method 1 potential problems, you can still stage deployments by populating a temporary group with a subset of PCs and assigning program to only that group. You can even have a permanent "Beta" testers group, if you'd like...
What worked for us great in the past (environment w ~1000 PCs, 10 sites) for Software Distribution was a single policy with all the software going through it via ACL. There were security groups set up for individual software items (even versions, if necessary), as well as department suites (e.g. Marketing gets Adobe Photoshop + Quark + etc...)
Currently the policy contains over 200 items, and there seems to be no noticeable performance hit during bootup process.
Recently we became part of a larger corporation (35000 PCs, and 70-some sites). Their philosophy was different from ours, and they seemed to be torn between Method 2 and Method 3. It is pretty dismal - 700 policies, most of them are either empty, or test, or not even applied. Not that I am implying that taking either of those routes guarantees you a fiasco, but maintaining a large number of "smaller" policies does become an overwhelming task unless someone enforces discipline and proper control of GPO lifecycle. Little easier if you have a formal Change Control process.
As far as Method 1 potential problems, you can still stage deployments by populating a temporary group with a subset of PCs and assigning program to only that group. You can even have a permanent "Beta" testers group, if you'd like...
Posted by:
jib
16 years ago
Good first post that I'd love to discuss more in detail but for now ..
This is what I'd recommend. I'd even recommend it as a general way of assigning policy to client computers.
Yes and no. If you have the money, then go buy a SMS something, you'll feel more elegant [:D] If not, you'd be best off with a combination, but using GP as base. Writing msi-wrappers for scripted deployment of stuff you don't want to push as msi is NOT as hard as some people want you to think.
At my former employer we pushed this far and had in excess of 600 software GP polices. Each and every one of them applied only a single software, each and every one of them assigned through group membership filtering, only computer policy, no user assigned software. Computer account logon times where not instant but not bad, policy processing would take up to a maximum of maybe 30 seconds. Wake-on-lan in the morning to push stuff before users were in was considered but not implemented before I left the organization. User logons were not affected.
ORIGINAL: cellardoor
There might be some other methods like setting up Groups and using GP permissions to control where its applied.
This is what I'd recommend. I'd even recommend it as a general way of assigning policy to client computers.
ORIGINAL: cellardoor
does everyone tend to use SMS or something in large organisations?
Yes and no. If you have the money, then go buy a SMS something, you'll feel more elegant [:D] If not, you'd be best off with a combination, but using GP as base. Writing msi-wrappers for scripted deployment of stuff you don't want to push as msi is NOT as hard as some people want you to think.
At my former employer we pushed this far and had in excess of 600 software GP polices. Each and every one of them applied only a single software, each and every one of them assigned through group membership filtering, only computer policy, no user assigned software. Computer account logon times where not instant but not bad, policy processing would take up to a maximum of maybe 30 seconds. Wake-on-lan in the morning to push stuff before users were in was considered but not implemented before I left the organization. User logons were not affected.
Posted by:
cellardoor
16 years ago
ORIGINAL: revizor
What worked for us great in the past (environment w ~1000 PCs, 10 sites) for Software Distribution was a single policy with all the software going through it via ACL. There were security groups set up for individual software items (even versions, if necessary), as well as department suites (e.g. Marketing gets Adobe Photoshop + Quark + etc...)
Currently the policy contains over 200 items, and there seems to be no noticeable performance hit during bootup process.
Thanks very much for your post revizor. It's some what comforting to know how other people do it and that it works. I did find an interesting example of a software deployment model at http://www.wolftech.ncsu.edu/support/support/Active_Directory/Software_Distribution which use's groups to control deployment. It seems to me, you either have lots of GPO's or lots of Security Groups but they kind of do the same thing.
If I've understood you correctly. You had one Software GPO linked at each office ou level and you added all your packages to this. So you must of removed authenticated users from the GPO security and added a security group for each office with the apply GPO setting? That way you were able to stage the install. But how are you able to install certain software for the Marketing department and say beta testers? Are you also setting permissons on the individual packages in the GPO? I've not done any testing with this but I imagine you could remove the inherited GPO permissions or put a deny on the offices you don't want to have it at individual package level?
My hand has been forced a little with people pressuring me to get software installed and I've kind of started doing it the way I outlined in method 4. I'm already worried there will be a lot of GPO's. You've given me food for thought though and its not too late to change. I'm going to do some testing.
The thing I'm paranoid about is having to make changes at a later date. How for example do you handle redeploying an application at say one office without having to do all of them?
Also, what if you need to change the order of the way the packages are installed. For example we have one particular program that needs dot net to work so I always install this first and then my program after. How would you handle this later on down the line when you have a list of 10 programs setup and for whatever reason you need to push something to the front of the queue?
Cheers,
Cellardoor
Posted by:
cellardoor
16 years ago
ORIGINAL: jib
Yes and no. If you have the money, then go buy a SMS something, you'll feel more elegant [:D] If not, you'd be best off with a combination, but using GP as base. Writing msi-wrappers for scripted deployment of stuff you don't want to push as msi is NOT as hard as some people want you to think.
Hi Jib. Thanks for your reply. Yes. There's no money to purchase a deployment system so it's a case of making use of what we got. How does the MSI wrapper work? Is it a case of making a package out of a batch file or vb script so you can deploy it with AD?
Is the way you did it the way I described as method 3? One GPO for each application. Would this be linked once at the top of your OU structure or multiple times at individual office OU level? If I do link it at individual office OU level do I really need to use security groups as well? Maybe only when I want to put a deny permission in for a certain group of computers?
Sorry for all the questions. It just seems there are so many things to consider. Once you've committed to one way of doing it you've kinda gotta roll with it.
Posted by:
cellardoor
16 years ago
ORIGINAL: revizor
What worked for us great in the past (environment w ~1000 PCs, 10 sites) for Software Distribution was a single policy with all the software going through it via ACL. There were security groups set up for individual software items (even versions, if necessary), as well as department suites (e.g. Marketing gets Adobe Photoshop + Quark + etc...)
Currently the policy contains over 200 items, and there seems to be no noticeable performance hit during bootup process.
Hi Revizor. Another thing I've wondered about. Do you not have the need to use WMI filters? I just wondered what you would do if you wanted to install the Office Compatibility Pack for example. Shouldn't you really do a WMI filter for the version of office? This would be a bit hard to do if you have 200 different software items all in one GPO and you only want to apply a WMI filter for one particular software package.
The more I think about it, maybe one GPO for each bit of software might be the answer, applied at numerous offices using Security Groups to control installs. But then I wonder what order the GPO's get applied. Going back to my example of having to install dotnet before a program. In testing I put dotnet in one GPO and my program in another GPO and it applied my program first which of course didn't work. Maybe the answer is WMI filters again.
Sorry for all the questions. Its just what ever path I choose I seem to keep finding potential stumbling blocks.
Cheers,
Cellardoor
Posted by:
cellardoor
16 years ago
Sorry Jib. I have a couple more questions.
1) Do you ever need to use the redeploy functionality? I'm wondering what you would do if you wanted to selectivily redeploy an application.
Maybe the workaround is create a new GPO instead? I haven't tested it but I imagine AD will re-install it.
2) A similar question. Do you ever use the remove and uinstall functionality? Again I'm wondering how you could stage this.
Part of me thinks its a good thing to remove it and uinstall the software everywhere in one fell swoop (if required). Thinking maybe redundant software. Maybe to stage it, you could script something to uninstall it and put it in the startup script for that office.
Both seem like acceptable workarounds.
1) Do you ever need to use the redeploy functionality? I'm wondering what you would do if you wanted to selectivily redeploy an application.
Maybe the workaround is create a new GPO instead? I haven't tested it but I imagine AD will re-install it.
2) A similar question. Do you ever use the remove and uinstall functionality? Again I'm wondering how you could stage this.
Part of me thinks its a good thing to remove it and uinstall the software everywhere in one fell swoop (if required). Thinking maybe redundant software. Maybe to stage it, you could script something to uninstall it and put it in the startup script for that office.
Both seem like acceptable workarounds.
Posted by:
revizor
16 years ago
If I've understood you correctly. You had one Software GPO linked at each office ou level and you added all your packages to this. So you must of removed authenticated users from the GPO security and added a security group for each office with the apply GPO setting?
Not quite. In our case, all our OUs were grouped underneath one root level OU, so I just had one link. I did not have to remove Authenticated Users from the ACL in Software policy (otherwise, PCs would be denied access to process that policy all together, if you think about that). I just set up ACLs on individual package level inside the GPO - you should see "Security" tab in package properties (let me know if you don't, there may be a need to enable advanced options for that), this is where you do most of your magic. Staging deployments is as easy as gradually populating your target security group, or adding an existing security group to the ACL. My Beta group was comprised of a number of "advanced" users and their PCs I performed pre-flight deployment testing with. You have to be extra cautious when adding new software to the policy, always double-checking ACLs on every package that you add - mistakes do happen when setting up permissions, and with software policies they are pretty darn obvious. You don't want to accidentally push some specialized (and licensed) software company-wide because you forgot to remove Authenticated Users from the ACL.
In your particular case, it depends on your AD hierarchy, but there's nothing preventing you from linking the same policy to multiple OUs of your liking.
Also, what if you need to change the order of the way the packages are installed.
The example when installation of Software X requires .Net Framework 2.0... Computer reboots. Say, X tries to install, and fails, since it doesn't find .Net on the system. Application Error Log entry is generated for that item, and the software policy advances to the next item, which is incidentally .Net Framework 2.0. Next reboot, and X tries to install itself again, finds .Net Framework, and completes successfully. Nothing you had to tweak, other than reboot PCs twice. In the most simple scenario, the sequence of the application installation follows the sequence of software assignments. If you want to change that, I believe there was a forum thread about a year or so ago here describing how it was possible, but there was no elegant solution offered...
Do you not have the need to use WMI filters?
Looked into using them, but couldn't find real application for us. You see, at the time my group had total control over the infrastructure, from OS, software, hardware, AD, SMS, RIS and other angles, so we promoted hard our the standardization efforts ensuring minimal number of hardware models, single OS, single build process, everyone on the same version of applications. Just about anything was standardized, with a minimal number of odd configurations limited basically to members of our team. So, I can't say WMI filters is the subject I am familiar with first-hand. But, depending on how you approach it, you may find those very useful in your infrastructure (like excluding all the servers from your Software Policy scope, for example. With us, we are even deploying Terminal Servers with the same policy - makes it fewer places to make the changes to :-) ).
Do you ever need to use the redeploy functionality? I'm wondering what you would do if you wanted to selectivily redeploy an application.
Just right-click on the package name inside the policy, and pick "Redeploy". As easy as that... I do this for one of our internal apps that gets regularly updated.
Do you ever use the remove and uinstall functionality? Again I'm wondering how you could stage this.
Remove works as good as the msi package performs uninstall. If you plan on staging removals, one thing you may want to do is check the box "uninstall when the software falls out of scope"... Then by virtue of ACL'ing Deny permission, you can achieve your goal of staged removal.
A couple of point here. With a single policy, when upgrading the package, the UI will actually show you which package is getting upgraded. When using separate policies, it won't (but you can manually find related upgradable package if you choose). Not a big deal, since package upgrades will happen one way or another with proper upgrade codes contained within MSI, but nonetheless...
And, whichever route you're about to take, you don't want to rush, because, if you change your mind later down the road, it'll more than likely involve redeployment of affected packages (sometimes users get frustrated and hit power button in the middle of a lenghthy install)...
Posted by:
contra
16 years ago
Firstly, great thread lads.
A few questions:
As far as order processing is concerned does it install the apps from highest to lowest precedence order IF you have one GPO per application ?
Does it only install at startup ?
How to enforce a reboot? and also if it knows its installed, it wont install again will it (making an endless rebooting loop) ?
A few questions:
As far as order processing is concerned does it install the apps from highest to lowest precedence order IF you have one GPO per application ?
Does it only install at startup ?
How to enforce a reboot? and also if it knows its installed, it wont install again will it (making an endless rebooting loop) ?
Posted by:
cellardoor
16 years ago
Hi Contra,
Glad this thread is still sparking some interest. I'm still in the early stages of deploying software myself only deploying two applications, but I will try to answer some of your questions.
Can't answer this one. I've not tested it and it doesn't bother me what order it's done in.
If you choose to assign the software to the computer (what I've done), it will install the application using the system account before the user has logged on and the Ctrl-alt-del screen appears. It will simply displaying a message saying something a long the lines of "installing managed software my program client blah blah" so the user will know it's actually doing something and hasn't frozen.
You shouldn't need a reboot, as you are installing with the System A/C before the user has logged on so no files should be in use etc.
If its been installed by GPO, it won't keep trying to install the software once successfully installed. Either way, it won't reboot after a successful install or a failed install. It will just display the Ctrl + alt + del screen for the user to log-on. I've certainly seen cases where it's seen slightly different versions installed and tries to remove them before installing from GPO. Sometimes it can't do it and it will keep trying everytime the computer is started. In this case, you will no doubt get a call from the user asking why it keeps saying its installing z program every morning. If you wanted to stop this happening in the first place, you could maybe use a batch file to silently uinstall old versions first. The following free software might help if you want to deploy software out of hours. Should allow you to start computers up remotely and shut them down when you're done with them. http://www.specopssoft.com/products/specopsgpupdate/
Personally I don't think AD Deployment works that well, where you are say installing MS Office to your whole organisation and you already have a mix of different versions installed.
For big programs like that, I only deploy to new computers where I know the program is not already installed otherwise it just gets messy. Others might have a different opinion.
Glad this thread is still sparking some interest. I'm still in the early stages of deploying software myself only deploying two applications, but I will try to answer some of your questions.
As far as order processing is concerned does it install the apps from highest to lowest precedence order IF you have one GPO per application ?
Can't answer this one. I've not tested it and it doesn't bother me what order it's done in.
Does it only install at startup ?
If you choose to assign the software to the computer (what I've done), it will install the application using the system account before the user has logged on and the Ctrl-alt-del screen appears. It will simply displaying a message saying something a long the lines of "installing managed software my program client blah blah" so the user will know it's actually doing something and hasn't frozen.
How to enforce a reboot?
You shouldn't need a reboot, as you are installing with the System A/C before the user has logged on so no files should be in use etc.
and also if it knows its installed, it wont install again will it (making an endless rebooting loop) ?
If its been installed by GPO, it won't keep trying to install the software once successfully installed. Either way, it won't reboot after a successful install or a failed install. It will just display the Ctrl + alt + del screen for the user to log-on. I've certainly seen cases where it's seen slightly different versions installed and tries to remove them before installing from GPO. Sometimes it can't do it and it will keep trying everytime the computer is started. In this case, you will no doubt get a call from the user asking why it keeps saying its installing z program every morning. If you wanted to stop this happening in the first place, you could maybe use a batch file to silently uinstall old versions first. The following free software might help if you want to deploy software out of hours. Should allow you to start computers up remotely and shut them down when you're done with them. http://www.specopssoft.com/products/specopsgpupdate/
Personally I don't think AD Deployment works that well, where you are say installing MS Office to your whole organisation and you already have a mix of different versions installed.
For big programs like that, I only deploy to new computers where I know the program is not already installed otherwise it just gets messy. Others might have a different opinion.
Posted by:
miclarke
16 years ago
I am currently working with 2 clients looking for individuals who are strong in SMS and Group Policy, both are permanent positions and one is working with the Olympics, and driving the IT infrastructure behind it. If interested please email me at [email=miclarke@teksystems.com]miclarke@teksystems.com[/email]. Any referrals are also appreciated.
Cheers,
Cheers,
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.