[gptalk] Re: Determining if Group Policy Deployment is right for us....

  • From: "Darren Mar-Elia" <darren@xxxxxxxxxx>
  • To: <gptalk@xxxxxxxxxxxxx>
  • Date: Mon, 3 Mar 2008 17:20:14 -0600

What I was referring to back then was a more friendly UI for GP Software
Installation. It was essentially to be an enhanced version of my GPSIViewer
utility out on gpoguy.com. However, its been put on the back burner for
quite a while now. Essentially, though, all it did is put a better face on
GPSI-making it easier to, for example, to view all deployed applications in
a domain, and ultimately, to be able to easily add, change and remove all
apps from a package centric view. If folks think its something that would be
interesting I'd love to hear about it. It would not likely be free, however,
though probably cheap.






From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On
Behalf Of Michael Pietrzak
Sent: Monday, March 03, 2008 5:06 PM
To: gptalk@xxxxxxxxxxxxx
Subject: [gptalk] Re: Determining if Group Policy Deployment is right for




I remember Curt over at the minasi forums mentioning something about you
developing a software deployment application. Was there ever anything like
that that you were working on?






From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On
Behalf Of Darren Mar-Elia
Sent: Monday, March 03, 2008 2:41 PM
To: gptalk@xxxxxxxxxxxxx
Subject: [gptalk] Re: Determining if Group Policy Deployment is right for



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.





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

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.


Other related posts: