Matt- Lots of questions in there but I would say that GP will almost meet your requirements. The only one that really stands out is the need for no reboots. In general, if you deploy per-computer, then you need to reboot for a machine to pick that up. Same goes for per-user installations requiring a user to re-logon to pick up the package. Otherwise GP fits most of your requirements. You would need to package your DLLs as an MSI package, which is not a big deal if your company developed them, or even if they haven't with packaging software. As for updates, you can use GP to create "upgrade relationships" between, for example, v1 and v2. The package in v2 has to know how to handle upgrading v1 but otherwise, it works as expected and it allows GP to handle when to update an application. As for 3rd party products, there are many, many software distribution solutions out there. I would say that only a small subset of them rely on GP. One of the notable ones is SpecOps Deploy. But you have many, many 3rd party distribution solutions out there to choose from. Darren From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On Behalf Of Matt Walker Sent: Monday, March 03, 2008 3:58 PM To: gptalk@xxxxxxxxxxxxx Subject: [gptalk] Determining if Group Policy Deployment is right for us.... Hi all, We are currently in the process of creating a new application which will house all the logic on a server and have workstations hit that. The workstations will need some .dll's, etc. installed to allow the integration with some other third party applications. It is the desire to have these components installed on the workstations with the following points in mind: Ease of installation with little to no user interaction No need to have admin rights on the workstation No need to reboot the target workstation Ability to self update Ease of uninstallation. With these in mind, will Group Policy work for us? I know it may be difficult to determine without knowing the actual footprint of the workstation components. In reading some Group Policy information, a question does arise for me. What method would I use since this package that will be installed will not really be a functioning application, but simply unrelated components? There are no real entry points to this 'application' that would be installed. Would I assign this package to a computer/user? In other words, this package should be installed always. Then, down the line, we would want to be able to upgrade, remove, etc. If upgrading, how does that actually work? I know how to upgrade simply using the Windows Installer methodology, but how does that fold into Group Policy. In using group policy for this purpose, would I just be telling the system to install this .msi then, based on its internal codes, upgrade accordingly? Is there any way to detect when an update is needed or is it simply the job of the Administrator to monitor this and employ a new policy to push the update? Any help is greatly appreciated so I thank you in advance. I read up on third party deployment tools and many seem to be wrapped around Group Policy in some way. Is this an accurate statement or do many tools handle pushing software differently? Again, thanks for the help!! Matt Walker Installation Development Synergis Software 472 California Road | Quakertown, PA 18951 Phone: 215.529.9900, x192 | 800.836.5440 Fax: 215.536.9249 <http://www.synergis-adept.com/> www.synergis-adept.com Simple, Powerful Document Management This message (and any associated files) is intended only for the use of the individual or entity to which it is addressed and may contain information that is confidential, subject to copyright or constitutes a trade secret. If you are not the intended recipient you are hereby notified that any dissemination, copying or distribution of this message, or files associated with this message, is strictly prohibited. If you have received this message in error, please notify us immediately by replying to the message and deleting it from your computer. Messages sent to and from us may be monitored. Internet communications cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Therefore, we do not accept responsibility for any errors or omissions that are present in this message, or any attachment, that have arisen as a result of e-mail transmission. If verification is required, please request a hard-copy version. Any views or opinions presented are solely those of the author and do not necessarily represent those of the company.