Deploying MSI via GPO

F

FoxFlame

Limp Gawd
Joined
Sep 3, 2005
Messages
143
I'll try to make this a very simple question, as it is attached to a much larger project. (I'm not even sure if this is in the correct forum. It's kinda all over the place)

The Question:
What is the fickle and seemingly magical reasoning for when a GPO is applied versus when it's not? Does it matter if I format the system and reinstall? It does check and notice that all the applications it is supposed to have reinstalled aren't there, right?

UPDATE: I think I figured it out: There's a delay mechanism isn't there? A time-out? A delay before GPO is applied? Like after a format or something? How long is it? Or am I completely wrong?

(NOTE: I have set the system to 'wait for network' on boot, so it should be checking GPOs.)

The Background:
Right now I'm attempting to assign Office 2k3 to systems on a domain. There is only one system in a testbed OU with a software installation GPO assigned to it. Ignoring the permission issues I'm running into occasionally (I realized I needed to set permission based on computer, not users) and the problems slipstreaming SP3 into the AIP (I hope the install I'm doing now will fix that; I believe it was the short file names problem) I'd just like to know why the system seems to ignore the GPOs after a format...or whenever it feels like it.

I've dated women who are more consistent. I've got MSI that properly install, not being installed on the system, let alone the MSO install. This is typically after I reimage, or reinstall the system, and add it back to the domain. Do I need to remove them from AD, then add them back to the directory and move that system to the correct OU? Or am I simply doing something incredibly wrong?

I'm the kind of guy who will go through and learn something himself, researching the hell out of a subject, before asking questions. But this problem is too inconsistent for me to do that, so I'm asking for the help of those who have done this before me. I should just go and study for my MCSE already. I bet this is in there somewhere...

Thank you very much for your time and wisdom,
--Fox

Edit: SP3 slipstream worked! ^_^ Now if I could just get it to dependably install by itself...
 
Last edited:
Solution:

gpupdate.exe

It is a timed thing. 90 minutes +/- 30. (default) running gpupdate forces the update then.
 
You should really use a deployment solution for images and packages such as Altiris or a similar product.

As far as GP being applied "after a format", you have to add the computer to the domain and the correct OU. Generally the GP is updated upon reboot/logon/or gpupdate/force.
 
I should probably have noted that the system was never removed from the domain, just formatted and rejoined, so it was never taken out of the OU.

I thought the GP would update after I formatted, reinstalled, and joined to the domain, but it would just reboot and no software would be installed until I ran gpupdate, or let it sit for a long while and then reboot.

I am using a Symantec ghost server when I get the systems to the situation I want them, to take an image, but to cut back on image size and storage, I'm leaving all software to be installed off the system. I'm simply attempting to get them to the point where all I need to do is clone them, then reboot and let them pull all the software they need installed directly afterwards. This way if/when I screw something up they get the current load-out.

Thanks for the suggestion, I'll look into Altiris, but cost considerations will need to be put into place, and how difficult it is to make an MSI file for certain software. (I'm setting up a clean system now for MSI packages.)
 
While this doesn't directly answer your question, I'd take a look at WPKG for package deployment. If you can install a package via command line, you can use WPKG.
 
I never consistently had problems with group policy, only the odd issue here and there.

What I found is that a fresh install always requires 2 reboots after joining the domain to apply group policy settings, but interestingly, any changes to group policy you make will take effect after just one reboot of a client that is already on the domain.

I also found that specifying the scope of a policy produces better results for deploying software as apposed to leaving it on "authenticated users", so using your example of deploying Office 2003, I would create a group in AD called "Software - Office 2003" and add all the computers to that group, then create the GPO, put the software installer in the GPO making sure to check "uninstall when the policy no longer applies" and then under "scope" remove "Authenticated users" and add "Software - Office 2003".

Software should be deployed in a 1 software package per GPO type setup.

Also, make sure you disable the part of the GPO that is not used, you have 2 parts, computer policy and user policy, so if you are deploying software, disable the user policy, that way the machines do not have to apply policy that has no settings.

And finally, I found that GPO can be a bitch if you have too many settings, I recently went through an overhaul of GPOs on our domain where way too many settings existed, and I ended up deleting all my GPOs and starting again, after removing a lot of un-necessary settings everthing runs way smoother.
 
XOR: Thanks, looking into it now. Finding proper MSI files is a pain in the arse, and making them might be an even bigger pain. I was originally hoping you could create MSI simply with command line flags of the exe.

Demios, I'll be sure to use a separate GPO for every published software package. Right now the only ones I'm using are assigned, so I'm just using systems in an OU, and permissions are set to "Domain Computers", as I'm not horribly concerned if one of my users were to find a way to install software in this list as...well, it should already be on their system.

The part about too many settings exist: Is that per GPO, or as in all GPOs combined? That's very disheartening to hear that GPOs can only handle so many settings. I'm using them to lock down my client systems to avoid...well, user stupidity.
 
FoxFlame said:
XOR: Thanks, looking into it now. Finding proper MSI files is a pain in the arse, and making them might be an even bigger pain. I was originally hoping you could create MSI simply with command line flags of the exe.
Click to expand...
Ya, no such luck , huh? You can do that with the big ones ( adobe for example ), but a lot of other packages are just brain dead in how they install ( ultravnc...don't get me started ).

The beauty of wpkg is that it handles anything that can be installed via command line. EXEs, batch files, msis..all of it. And it's better than GPO MSI deployment because it's more flexible.
 
I'm curious what issues you had with UltraVNC? The creation process? I'm only wondering as that's one of the packages that is auto-deployed to my domain, and I just wanted to make sure there aren't known issues with it that I missed. (it /seems/ to be working just fine, but I did that so long ago I can't recall how it was configured)
 
FoxFlame said:
I'm curious what issues you had with UltraVNC? The creation process? I'm only wondering as that's one of the packages that is auto-deployed to my domain, and I just wanted to make sure there aren't known issues with it that I missed. (it /seems/ to be working just fine, but I did that so long ago I can't recall how it was configured)
Click to expand...
This is my wpkg script:
Code: 
<?xml version="1.0" encoding="UTF-8"?>
<packages>
  <package id="UltraVNC" name="Ultra VNC" revision="1065" priority="5">
    <check type="uninstall" condition="exists" path="UltraVNC 1.0.6.4" />
    <!-- <check type="registry" condition="exists" path="HKLM\SYSTEM\CurrentControlSet\Services\mv2\Start" /> -->

    <install cmd="net stop uvnc_service">
      <exit code="0" />
      <exit code="2" />
    </install>
    <install cmd="sc delete uvnc_service" />
    <install cmd='%SOFTWARE%\ultravnc\UltraVNC_1.0.6.4_Setup.exe /verysilent"' />

    <install cmd='%comspec% /c copy /Y %SOFTWARE%\ultravnc\ultravnc.ini "%ProgramFiles%\UltraVNC\"' />
    <install cmd='%comspec% /c copy /Y %SOFTWARE%\ultravnc\rc4.key "%ProgramFiles%\UltraVNC\"' />
    <install cmd='regedit /s "%SOFTWARE%\ultravnc\ACLVNC.reg"' />
    <!--    <install cmd='%comspec% /c mkdir "%ProgramFiles%\UltraVNC\driver"'> 
      <exit code="0" />
      <exit code="1" />
    </install> -->
    <!-- <install cmd='%comspec% /c xcopy /Q /Y /S \\sunpro\apps$\ultravnc\driver "%ProgramFiles%\UltraVNC\driver\"' /> -->
    <install cmd='"%ProgramFiles%\UltraVNC\MSLogonACL.exe" /i /o %SOFTWARE%\ultravnc\acls.txt' />
    <!-- <install cmd='%comspec% /c start /WAIT "Mirror Driver Install" /D"%ProgramFiles%\UltraVNC\driver\XP" "%ProgramFiles%\UltraVNC\driver\XP\setupdrv.exe" install' /> -->
    <install cmd='"%ProgramFiles%\UltraVNC\winvnc.exe" -installs' />


  </package>

</packages>

Not only do you have to install the exe, then you have to push the config file AND apply a reg file if you want NT authentication. You then have to manually install the service.

The mirror driver is even more fun. It won't install in any background capacity. Even though the actual command is simple, it needs to be run by the currently logged in user. Can't run it in the background as admin or SYSTEM. And of course all my users are limited users, so the install in the foreground doesn't work.

If it weren't for the fact it has features I need, I'd have kicked ultravnc to the curb and never looked back after trying to get it to install unattended cleanly.
 
Oh, I misunderstood. I was under the impression there was difficulty deploying UltraVNC via GPO. I'm tempted to play with mine a bit, but as it's working, as long as I can remember the passwords I believe I'll leave it be.

Seems there are some easier to deploy via GPO, and others easier (or only able) to deploy via WPKG.

I'll have to test WPKG after the sites are setup properly and working. Deploying Chrome via GPO or WPKG seem to both have limitations, and is one install I'd really like automated and available to every machine. (Not every user) On that particular app I may simply "Publish" via GPO.

Honestly by this point if I can find one surefire method to deploy any application across all systems I'd prefer to just stick with it, but sometimes, even when you've the best multi-tool in the world, the job just calls for a hammer, so it's good to have options.
 
FoxFlame said:
Oh, I misunderstood. I was under the impression there was difficulty deploying UltraVNC via GPO. I'm tempted to play with mine a bit, but as it's working, as long as I can remember the passwords I believe I'll leave it be.

Seems there are some easier to deploy via GPO, and others easier (or only able) to deploy via WPKG.

I'll have to test WPKG after the sites are setup properly and working. Deploying Chrome via GPO or WPKG seem to both have limitations, and is one install I'd really like automated and available to every machine. (Not every user) On that particular app I may simply "Publish" via GPO.

Honestly by this point if I can find one surefire method to deploy any application across all systems I'd prefer to just stick with it, but sometimes, even when you've the best multi-tool in the world, the job just calls for a hammer, so it's good to have options.
Click to expand...
True, simple MSIs which don't require much beyond a simple install command work well with the GPO deployment.

WPKG does handle those and more however, which is why I use it. It covers anything I may possibly need.
 
FoxFlame said:
Demios, I'll be sure to use a separate GPO for every published software package. Right now the only ones I'm using are assigned, so I'm just using systems in an OU, and permissions are set to "Domain Computers", as I'm not horribly concerned if one of my users were to find a way to install software in this list as...well, it should already be on their system.

The part about too many settings exist: Is that per GPO, or as in all GPOs combined? That's very disheartening to hear that GPOs can only handle so many settings. I'm using them to lock down my client systems to avoid...well, user stupidity.
Click to expand...

If you are not going to use a specific group to assign apps, don't change the default scope, there is a reason it is set to "Authenticated users" (only Microsoft is wise about why) and there is no benifit to changing it, users cannot uninstall software that is assigned to a PC no matter what the GPO permissions are.

Also, I found that it is best to ONLY change the scope, don't mess with any other GPO permissions (for example, delegation) unless you want to find something new to break/fix. if you check delegation after changing scope you will see that permissions are changed appropriately, and there is no reason to go messing with any of the other permissions set (trust me, I know from experience, its best not to play with it).

When I say too many settings, I mean all GPOs combined, you need to try and keep things as simple as possible, and its really hard to avoid duplication if you have a lot of different GPOs with all sorts of settings, your example of locking down settings for users is a perfect example, if you want to set user settings, you need to go through each setting that you are considering locking down and ask yourself, is it really necessary to lock down a given setting.

You also need to consider if the setting you lock down may cause you more work rather than less (I have locked down settings only to go back and "un-lock" them later because I had more work because of it), and also consider the default behavior of a given setting, for example, I used to specifiy time sync options, but during our recent GPO overhaul I considered what the default behaviour is and decided that default is fine, and setting up time sync options is unnecessary.

And finally, you need to consider that each new setting or GPO is going to increase startup time, because each new setting or GPO needs to be applied every time a machine starts, and another set of GPOs is applied at logon.

When I looked at our organisation there were a number of factors that ended up in us deciding that certain things are not worth the time wasted on troubleshooting, such as Roaming profiles and Installing apps with GPOs (not enough machines to justify the effort of deploying apps), like I said, you realy have to weigh up wether a given setting or feature is giong to increase or decrease your workload (roaming profiles are a pain in the ass by the way).
 
Zero, I'm going to be playing with WinInstaller in a VM environment to try to create some of my own MSI deployment packages. Tons of distractions have derailed this project.

Tons of great advice. Thanks Demios. I made that mistake with enabling "Turn On Classic Shell" and suddenly no one could have anything but an Icon listing in explorer. (This doesn't seem to be a documented side effect.)

I've decided a laissez-faire approach to GPO is best. As a network administrator, stopping security breaches before you think of them by locking down everything (Need to know) so there isn't a potential breach somewhere you didn't think of it doesn't seem to apply to GPOs.

They do come in handy for some things...but others just make you go nuts. I've one GPO with a few settings I want to apply to everyone, and others for specific users or computers.
 
You must log in or register to reply here.
Back
Top