GPO Redeploy

[Michele Cardone]

For DR reasons we had disabled all our deployments via GPOs for a week.
When they where relinked users started to reinstall software they had
already installed. Has anyone seen this or have any ideas what I should
look into to stop this.

Thanks

 

[Darren Mar-Elia]

GP Software Installation will normally only reinstall if the package was
removed or something was missing in the install (i.e. a key file was
deleted). You could turn on software installation logging (see my gpolog.adm
file at www.gpoguy.com/gpolog.htm) and see why it think it needs to
reinstall.

Darren

--
Darren Mar-Elia
MS-MVP-Windows Server--Group Policy
http://www.gpoguy.com -- The Windows Group Policy Information Hub:
FAQs, Training Videos, Whitepapers and Utilities for all things Group
Policy-related
Group Policy Management solutions at http://www.sdmsoftware.com

 

[Michele Cardone]

Thanks Darren, I applied the ADM to a system and look through the logs, the
only thing that stands out is:

Application PBApps from policy DEP_NY: PBApps6.60 was reset to reinstall
because an unmanaged application with the same product identifier was
already present on the machine.

Only problem is this makes very little sense to a few of us, unmanaged in
what way?

The GPO in question wasn't changed, it was disabled, but left linked to the
OU in question, after the DR test (actually a power outage of the entire
building) it was re-enabled. The GPOs where not edit in anyway to change
them.

Thanks again

 

[Darren Mar-Elia]

I suspect that what happened was that, when you disabled the link, but left
the software installed, it broke the relationship between the GPO and the
app. "Un-managed" means the app was not deployed via GP (or it no longer
thought it was). This means that, by default a managed app will always
uninstall and reinstall the same unmanaged app. Was the goal here to
basically prevent any new installs during your DR test? If so, then what I
would have done is changed the permissions on the MSI package so that new
users or computers could no longer read it (e.g. you could have moved the
MSI temporarily or just changed the perms on it). That would have prevented
them from successfully executing the MSI but would not have effected
currently installed systems.

Darren
--
Darren Mar-Elia
MS-MVP-Windows Server--Group Policy
http://www.gpoguy.com -- The Windows Group Policy Information Hub:
FAQs, Training Videos, Whitepapers and Utilities for all things Group
Policy-related
Group Policy Management solutions at http://www.sdmsoftware.com

 

[Michele Cardone]

Yes the goal was to not have the systems try and run an install that would
point to a network server that was done during the weekend process.

So if I'm following you then we either have to live with everything
reinstalling itself, come up with some way to prevent this (looking at a
scripting solution) or don't re-enable this deployments.

Thanks for the information