If the installation is assigned to the computer itself the program will be installed the next time it starts; you'll have to manually restart the server if there isn't some auto-restart mechanism.
If the program can not be installed without asking the questions, you wont be able to install it via GPO. You can initially test this by running msiexec /qb /i installer.msi; if it installs you should be fine; otherwise it will fail. Depending on the program you might be able to get around this by specifying properties for the installer.
When manually run properties are specified in the form msiexec /i installer.msi property=value and you can specify multiple properties. Check out the http://AppDeploy.com website for your app, it might have the information you need (if your app requires these properties).
You might also be able to create an Installer Transform (MST) that changes how the installer works slightly, thus allowing the program to be deployed. The usual tool to use is MS's Orca, which is part of the Platform SDK (IIRC). There are other tools available. The AppDeploy website might have info about writing an MST for your app; otherwise you'd have to learn Orca enough to fumble through it (hit-and-miss).
Rarely, the app vendor will publish information on how to write MSTs or Properties=Value pairs. (I love those vendors that do, makes my life a lot easier, especially with complex apps).
I'm looking around for a walkthrough, but not finding much. The basic publishing process in a GPO is pretty straight forward, the greatest difficulty is getting the MSI/MST files in order first.
Greetings from another non profit IS person. :)
How hard is it to deploy GPP? Given that Windows XP does not natively support this, right? We need to install the client side extensions?
GPP are pretty much straight forward if your systems are XP SP3 and recently patched. I've rarely seen problems related to the preferences. If you have WSUS already you should be able to check that all your systems have the necessary client installed.
Is GPP reliable on Windows XP SP3? Googling, I turned up some references to bugs and slow performance. Does this match the current status of this product?
I haven't had any major reliability problems after the client side extension issues listed above were worked out.
How does the performance/overhead of GPP compare to using a kixtart or vbscript for things like mapping drives and installing printers?
I'm assuming that you are referring to the desktop performance.. If so the speed between the two has been negligible in my environment.
What's a good practice to use for keeping track of successful/unsuccessful logins? Our current system seems to have too much overhead. Should this be stored in the Event log? On which machine? Centrally, or on the local desktop? We do use the logs as a debugging tool currently, and also to determine when a user last logged on to the domain.
We have a couple systems in place, a legacy system (very much like what you describe, I'd like to see it retired) and event log auditing for successful and failed login attempts. Enable the auditing on your domain controllers would be enough. I suggest using Splunk to collect your logs but that is a matter of choice.
What should I try to speed up our current Group Policy infrastructure? I think this is what takes a long time at startup. Any ideas for where to start troubleshooting this?
What are best practices for creating a modern logon system to deal with the tasks I mentioned? Map drives, map printers, install software, install patches and perform miscellaneous backup routines and the like. What tools do you like and recommend for this job?
I've had extremely good luck with the GPP listed above. The vast majority of startup tasks can be accomplished with a handful of GPP settings.
What's the best way to install software that isn't neatly packed in an MSI already? We are a non-profit and could get some software donations from Tech Soup of things like SCCM. But, I really don't know if this is worthwhile.
I highly recommend EminentWare. It's a paid product but not too expensive. It will deploy updates for your non MS products (I love the Java and Adobe updates) and allows you to package and deploy software.
What are the implications of upgrading our domain to Server 2008 R2 version, to allow us to make use of GPP? I should mention that we have two member servers on our domain that are running Windows NT. These are basically appliances used only for our voicemail system. I don't want these to break. We did have an issue with upgrading our domain controllers with SMB, but I was able to find the workaround of lowering security settings. Any gotchas if we upgrade domain version? It seems like the answer should be no, but I am hoping to learn about some real world experiences.
I can't comment, I'm still on 2003 functional level.
Best Answer
If you have the enterprise version of the software (easily determined by the presence of an "admin" folder in the root directory structure), you can run setup /admin and create an msp file. Put the msp file in the updates directory and run setup (from a logon script or similar); the setup program will now follow whatever settings you put in the msp file.
If you don't have an enterprise version (you get what you pay for); you have to install it manually on every computer (or do something different like AppV).