Link to home
Start Free TrialLog in
Avatar of BadPanda
BadPandaFlag for United States of America

asked on

Problem with group policy

I have recently started working with a customer that has multiple POS systems.  We migrated from a Windows SBS 2003 server to a 2011 SBS machine.  They had implemented group policy some years back for the purpose of preventing employees from accessing the internet and only allowing them access to the POS application.
All POS computers are in a container called POS.  All are XP machines.
So here is the problem.  Because these are all 32-bit computers, the 32-bit print drivers wouldn't work on the server.  This was fine; installed them locally.  However, one of the workstations 'XP6' isn't acting like the others.
I deleted the old printers, reinstalled the new ones.  Rebooted the computer and they all came up fine...or so it appeared.  I uninstalled an outdated AVG, which went fine.  Again, so it appeared.  When I rebooted the machine all my changes made were reversed.  The printers were still mapped to the old 32-bit server which is no longer on the network, and AVG acted like it never was uninstalled.
I used Your Uninstaller, reran the uninstall of AVG.  Same results.  There is no reinstallation of software as would happen; it's almost like a roaming profile or something is keeping not only all the settings but applications as well.  I'm at a loss and hoping for some direction here.
Oh; the person that put this system together has moved on and documented nothing.  I am shooting in the dark here.
Thanks everyone for the help!
Panda
Avatar of nettek0300
nettek0300

My guess is that there is a group policy that is mapping the printers and installing AVG.  You need to check the settings on your group policies.
Go into GPMC and go thru your Policies.  Being SBS there are a number of default GP's, so hopefully the tech who created any additional ones used some sort of naming convention that allows you to identify the ones created that are not defaults.  If not just trawl thru the ones that are there using the technique below.

To do this:
Go to Administrative tools and look for Group Policy Management Console
The GPMC management console will display the Forest, then the domain, Your domain name
You'll see a folder call Group Policy Objects
For each item in the list, select it and then in the right hand pane, select the Settings tab
You will now see the settings for the GP selected.  Click somewhere in the Right Hand Pane, press Control+F to search the values in the GPO, and enter the name of the device you are looking for

You could go direct to the printer mapping section, but this is a quicker way to go thru all of them.

When you find the GPO Object that has the redundant printer mapping, go back to the left pane and right click the GPO and choose Edit.
This will open the Group Policy Management Editor
The GP is divided into 2 areas User and Computer.
Drill down thru User then Preferences then Printers you'll see the printers being mapped by the GP in the right hand pane
Click on the redundant one in the right hand pane and chose delete
Avatar of BadPanda

ASKER

Thanks for the tips everyone.  I'll be onsite tomorrow to check things out and see what I can do.
Best regards,
Panda
While this may address the mapped printer problem, this doesn't seem to address my inability to make changes to the machine locally(i.e. installing local printers.)  Remember that part of the problem is that any changes I made were automatically prevented by the system, even though the changes I made APPEARED to occur in the system.
I would try to find out where this behaviour is coming from.

To check if it comes from Active Directory or is something happening locally on the PC, you could disconnect if from the network, and perform the software installation with a local copy of the setup program.

To find out if it's a default setting in Active Directory, or some specific AD configuration for this one machine, take it out of the domain, rename it, then put it back in (using a local admin account to login after the first reboot). Group Policy settings are always bound to the name of machines. It may end up in a different OU. If the restore doesn't happen after bringing it back into the domain, but happens after moving it into the previous OU, then the settings must be there.
msifox, that is a great idea.  Removal from the domain may be just what the doctor ordered.
Will try monday morning and let everyone know the results.  Thanks for the suggestions!
Hi BadPanda,

Group Policy settings can be applied in a number of ways, and removing it from the domain may provide a temporary reprieve, until you reconnect, at which time you'll most likely see the apps re-appear.  As an example, we use GP to lock laptops that are mobile so that the configuration is controlled and remains consistent with our PC config.

There are tools that allow you to identify these settings, but If you aren't familiar its best you walk thru the places these sorts of things can be set to get your mind around it.

Deployment Via Group Policy
Check to see if there are any Software deployment policies in place
Go into the GPMC and expand Computer Configuration > Policies > Software Settings > Software Installations.  You may find your AVG is being deployed from here (as well as other packages).  This GP setting automatically installs an app when a machine doesn't have it (such as when a new machine is joined to the domain, the Policy detects that AVG isnt there and installs it.
I'd also look in "User Configuration > POlicies > Software Settings > Software Installation while in the GPMC.

I'd also look to see if there are any Startup or login scripts running

While in the GPMC go to Computer Configuration > Windows Settings > Scripts > Startup, right Click Startup and see if any scripts are listed
While in GPMC go to User Configuration > Policies > Windows Settings > Scripts (Logon/Logoff).  Right click Logon to see if any scripts are being executed here.
Go into Active Directory Users & Computers, drill down Your Domain > My Business > Users > SBSUsers.  Right click a users account and and choose properties, then go to the Profile Tab, and look at the Login script field.
Group Policy allows you the administrator to enforce settings on Workstations on your domain.  In some cases you can set a config item, but allow the user to modify it.  On the other end you can set a config item and even when not physically connected to the domain, remains in force.


If you are supporting systems that use Group Policy (which is a powerful and very worthwhile tool) then I'd suggest doing some study on it.

Group Policy Preferences Overview
Group Policy Preferences Getting Started Guide

Group Policy is NOT the kind of place you "Tinker in" especially in your situation.  You run the risk of killing all the machines governed by the GP and be back to rebuilding all to get back to square 1
ASKER CERTIFIED SOLUTION
Avatar of Gary Coltharp
Gary Coltharp
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
There is a hint that can show you if this is a local feature or coming from the server:
If shutdown and reboot are both quick, then t's probably done locally on the PC.
There are tools that work like the snapshot feature of virtual machines.
In this case restoring the previous state means just deleting the snapshot.
This takes seconds, whereas reinstalling the old software would take minutes.
Deepfreeze IS installed Gcoltharp.  How do you get rid of it?
Sorry for the delay in closing.  Forgot the ticket was open.
Deepfreeze was installed and was the problem.  However, because I had worked at removing the computer from the domain at the domain controller but the PC still kept thinking it was in the domain (bacause of Deepfreeze) this really caused a lot of problems.
Problem was eventually solved once Deepfreeze was removed.  Thanks for the help everyone.