We help IT Professionals succeed at work.

New podcast episode! Our very own Community Manager, Rob Jurd, gives his insight on the value of an online community. Listen Now!

x

Active Directory Software Deployment

joedboswell
joedboswell asked
on
499 Views
Last Modified: 2010-04-19
oops.

Ok, so I created a software installation package, then, I deleted it from the Active Directory (AD) structure, but it is still trying to install itself and ruin my life across my network.  I have looked through SYSVOL and cant find anything on it.

Any help in tracking this thing down in AD would be a great help, like I said I went through the 50 or so policies in the Sysvol to no avail.  I would love a nice summary if anyone has one, on how AD works, what services it uses, what files it uses, where it stores them, etc.  Please o please!!!

Joe
Comment
Watch Question

>>Ok, so I created a software installation package, then, I deleted it from the Active Directory (AD) structure

Where did you create this and from where did you delete it?

Author

Commented:
Created in DevStudio 9, basically, its an MSI that wraps a few files and sets permissions (wish I could go back and kick my own ass for doing this one) on the folders it installs.

Then it went into the Machine Policy of All Computers, where it stayed for about a week, then I deleted it out of the policies, completely, link and policy.

There is a bit of a catch, there was like 3 different versions of the installer, all of which were handled quite differently and I cant remember how each was handled now but I believe only the last variant of the installer actually set folder permissions, one I deleted the MSI, then the policy, still looks for those to uninstall it from the clients, wont ever have those again, the others remove quite 'halfassed' they leave files around (probably again permissions) and they dont remove and restore the permissions they replaced.

Joe
Grrr....
Okay, was this a domain-wide applied policy? Was is applied to the Default Domain Policy?

Author

Commented:

No it was only applied to the client workstations and the rendernodes, although that is 99% of the computers here it is not all of them, so it was close to domain wide, but it was not on that level.  and no, not applied to the default domain policy.

Author

Commented:

No it was only applied to the client workstations and the rendernodes, although that is 99% of the computers here it is not all of them, so it was close to domain wide, but it was not on that level.  and no, not applied to the default domain policy.

So, what did you have an OU that contained all the client machines [or the 99% {smile!}] and applied the GPO there?

Author

Commented:
It was applied separately to 3 different OUs inside the All Computers OU, so yes, applied in there.
ALL COMPUTERS<----GPO applied not applied here, right?
  |
  |_DEPTA<----GPO applied here?
  |_DEPTB<----GPO applied here?
  |_DEPTC<----GPO applied here?

Author

Commented:
yep
Okay, so you deleted all of the GPOs?
Were these published or assigned to users or computers?

Author

Commented:
If I remember correctly, assigned to computers
So now, when the machines reboot, they are reinstalling the package?

Did you delete the entire GPO or the Software Installation entry?

Did you take a System State backup before the deletion?

Author

Commented:
Yes, when the clients restart its either trying to install or remove one of the 3...

Deleted the entire GPO

No...

Commented:
Unlock this solution and get a sample of our free trial.
(No credit card required)
UNLOCK SOLUTION
You may have a point, What, but somehow, I believe that this is imbedded locally on the workstations now. But, it is worth giving RSoP a shot, joedboswell. What I was hoping to do, joedboswell, was to restore within AD just the deleted GPOs then hopefully it would give you another shot at removing them properly.

Commented:
KingHollis - I didn't think windows was that smart. Have you ever seen it do something like this before?

If  joedboswell has removed all the policies and restarted the system (PC) would the GPO  not be applied, hence not try to install the non-existance package?

If you're correct then he's going to have to remove the install string for the MSI from each machine registry by another GPO (or by hand if he's feeling GPO-battered :-)) Ouch!

>>he's going to have to remove the install string for the MSI from each machine registry
This is my fear!

But, I believe that if the same GPOs that created these entries is restored to AD as if it never went away, you can properly reverse the effects.
Not sure if this will help, but have your installed the Group Policy Management Console and checked to see which GPO's (if any) are being applied to the clients?  

Author

Commented:
Well, I cant put back in the MSIs they are completely gone, and it wouldnt help much because there were different revisions of MSIs that I did, I imagine each was signed with different #s and whatnot.  So thats not an option.

I would think that these GPOs are being kept by the Clients because there isnt even a hint of the GPO that I can find, hint 'hat I can find', which is why I am looking for the Overall Summary of what AD does...

The RSOP is a good idea but I have no idea how to implement it, and while it does not look hard its 7:18pm here and I am a bit burned out for the day.  I will give the RSOP a try tomorrow and we will see where the GPO is coming from.

More to come tomorrow!

Author

Commented:
Alright.  Very very nice, started RSOP, found Cebas installation that is still being applied.  Now my next 2 questions are WHY!?!?  

Why in the hell is this policy still here? and how do I keep it from getting reapplied from the DC?

It feels like a created a damned virus, the thing just KEEPS COMING BACK!  Argh, just when you think its gone, it rears its ugly head again!!!

Joe
Gads!

Where is RSoP showing it being applied?

How many domain controllers do you have in your environment?

Author

Commented:
We have 3 DCs 2 local, 1 remote connected via VPN.

Ahhh.  I think I am a dumbass.  Didnt bother to think that maybe this policy got replicated over to our OTHER DC...  Thats why I cannot find it on our primary.  (Or what WAS our primary).

K so lemme check and see if this policy is coming from my OTHER DCs...  probably is.

Author

Commented:
K not anywhere on any DC...  However the installer files are still in the directory, and the GPO is still sitting here on the client.

Again, why?  Why is this thing still here?  Maybe I removed it incorrectly but WITHOUT putting it back together how can I find the link AD is using to bring this thing back?

Joe
Unlock this solution and get a sample of our free trial.
(No credit card required)
UNLOCK SOLUTION

Commented:
I can't believe that KingHollis is correct about the install and that a refresh of the GPO to the client machine won't remove the rogue install command.

Wouldn't be the first time I'm wrong though :-)
And have a nasty feeling he's on the money, but that so odd....


joedboswell - Question: If you have a clean machine (one that wasn't attached to the domain at the time of the orginal GPO deployment) then add it to the domain is the deleted GPO still trying to deploy?
If it is then it still exists in AD on a container somewhere.
If it doesn't then your mostly likely going to have to create another gpo to remove the install string for the MSI from each machine registry. Which is a bugger.





Author

Commented:
Yeah I just checked another machine that wasnt here about a month ago when the MSI went into effect.  No install policy.  These are being kept by the machines locally.

Jesus.  This seems like a VERY basic directory service implementation.  I have never used Netware (ok maybe once or twice about 5+ years ago but it didnt last long), but I imagine its not quite this 'fragile'...  But then Netware is on like version 6 too though right?

Anyways, I like AD so far, just need a better understanding on a more general scale, makes understanding why this is happening a little easier, that and the logic behind it as well.

Anyways, then, where can I find the MSI install string in the REG, creating GPOs is no big deal really (or maybe I am taking it a little less serious than I should be...) for us, at the moment we have around 80 clients 2 offices and 6 servers, and have just started getting used to this implementation, so far quite honestly, the risk/reward ratio is about even (only because I am an EXTREMELY green SysAdmin) because while AD is down, alot of the time we can still work and quite honestly compared to the rest of the industry our server and client uptime is MUCH higher than everyone else.
@What90-- I know it sounds too wierd to imagine, but remember that the GPO that installs the software communicates these instructions to the client machines or the user at boot, logon, or when published, at request. If the client/GPO link is severed improperly like via deletion [not an unassign] no instructions are given to the client to no seek or no longer seek to perform the GPO settings. Since GPOs are AD objects with SIDs, I don't think it will matter that you create a new GPO to remove these previous instructions. I believe that the original instructions are tied to the original GPO SID. So, what would happen is the new GPO would run and remove the .msi package, but the old registry or class resident instructions from the old GPO will continue to execute.

joedboswell,

If this is tied to an entry in the registry, you could create another GPO to change the registry settings across the board. But, you would need to find it/them in the registry. I would suggest searching the registry for the name(s) of the .msi packages and hope you find all the keys that relate to this issue. But I fear that the key(s) may be identified only by the SID of the old GPO. That is if it is in the registry at all. This could end up being an entry within a class or attribute of the computer object....

Commented:
KingHollis - I guess I wanted to believe it was more resilent, oh well



joedboswell,
Try looking in these registry around here for your MSI keys
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall
or
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Installer

Author

Commented:
Found a part in Windows\Current Ver\Group Policy

and thats the only one I found in the reg, I searched using the huge alphanumeric string that the Policy is using (I am assuming to uniquely identify itself). {BE2AD.... I will check those other 2 places as well and then reboot and check RSOP again and see what it says.

Joe
Common What90, this IS MS, right? {smile}

In truth though, AD is very solid, but it can be tempermental if the rules aren't followed. Then you end up as Sys Admin feeling like a C++ coder as you have to comb through the scads of LDAP entries to figure out what's what!

I would open REGEDIT and then highlight My Computer and do CTRL+F and search with what you named your packages. This may be in other parts of the hive than the obvious...Grrr...
That was supposed to say "com'on", What90...

Author

Commented:
So here was the problem(s) err the main problem.

The clients were not communicating with the DC, I was getting 1054 errors all over the place.  I have come to check the event viewer religiously but in this case I was (and still am) busy with like 50 different things around the office and I guess it slipped my mind, in any case, once the clients reconnect with the DC they stop complaining about all the uninstall errors.  If it is still installed on the client machine it stays there, which isnt the best but thats what RIS is for...

Either way, things are coming along nicely since I got rid of that error.  Now there are new errors of course but thats gonna be a different thread.

Thanks guys for your help/ideas.

Joe
Unlock the solution to this question.
Thanks for using Experts Exchange.

Please provide your email to receive a sample view!

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

OR

Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.