1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Best practice for installing software with group policy

Discussion in 'Software' started by cellardoor, Apr 2, 2008.

  1. cellardoor

    cellardoor Nibble Poster


    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. Initially I thought, using a namespace for the distribution point I could just setup one group policy called software for example and add all my programs to this. But now I'm wondering about the future and how easy this would be to manage. For example, if I add a new program to my software group policy at a later date, I don't necessarily want to install it everywhere at once. The paranoid me, even after lab testing would still want to do a pilot install to one office first.

    I'm just wondering how you guys tackle software deployment with group policy in a large organisation. Do you just use multiple GPs?

    Cheers for reading this. I'd be interested in your thoughts.

    Certifications: MCDST, MCSA
  2. greenbrucelee
    Highly Decorated Member Award

    greenbrucelee Zettabyte Poster

    I have never done this but I am sure you can write a script so the software installs from the one machine to all the others, there are settings within windows which allow you to do this.
    Certifications: A+, N+, MCDST, Security+, 70-270
    WIP: 70-620 or 70-680?
  3. cellardoor

    cellardoor Nibble Poster

    Hi, thanks for this. I'm really looking for best practice or recommended ways of set-up. The deployment itself works perfectly, it's just how to manage it over multiple sites (we have about 50 + offices).

    Certifications: MCDST, MCSA
  4. GiddyG

    GiddyG Terabyte Poster Gold Member

    You could put users in specific OUs in AD, for example Accounts, or Sales, and then have GPOs to install certian software to the users in those OUs.

    My understanding is that this can be rather restrictive though, as you are limited to OUs, whereas something like SMS allows you greater freedom when deciding what software to allow to be installed to certain users/machines.

    I am sure someone like BM, or Phoenix will be able to better answer the question though...
  5. BosonMichael
    Highly Decorated Member Award

    BosonMichael Yottabyte Poster

    GPOs can indeed be used to roll out application installations. However, test it first with a non-admin user test account. If that works, THEN roll it out to a production OU.

    That said, I've never been a part of a "large" network. We used Prism to roll out patches and installs on our 450+ user network.
    Certifications: CISSP, MCSE+I, MCSE: Security, MCSE: Messaging, MCDST, MCDBA, MCTS, OCP, CCNP, CCDP, CCNA Security, CCNA Voice, CNE, SCSA, Security+, Linux+, Server+, Network+, A+
    WIP: Just about everything!
  6. Luddym

    Luddym Megabyte Poster

    What I would say is, TEST, TEST, TEST. I killed quite a few pc's with a software pushout via GPO when it all went pair shaped.
    Certifications: VCP,A+, N+, MCSA, MCSE
    WIP: Christmas Drunkard
  7. cellardoor

    cellardoor Nibble Poster

    Cheers for your comments. As said before though. The actual deployment works fine and I'm comfortable with that side of things (testing done). My concern is more about group policy design.

    Even some of the books I've looked at seem to be quite vague in that area. They talk about software deployment and the different methods but don't really talk about best practice.

    For example,

    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. Harder to manage. Potential for mistakes and keeping things consistent.

    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?

    My boss is keen to just use an all in one VB script that will install software and printers depending on your gateway. I'm not sure about this. Seems a bit 'old skool'.

    Appreciate your comments.

    Certifications: MCDST, MCSA

Share This Page