How do I permanently remove from Active Directory, a package thatwas assigned to a computer?

[Steve Stormont]

I made a group policy called “Deploy Office XP”. In this policy, I
created a package for Office XP deployment which I assigned to a number
of computers in our office. Office XP is installed to those computers fine.

Now, say I want to assign Office 2003 to the same PCs and no longer
want to have them install Office XP, how do I remove the assigned Office
XP package from Active Directory so that it will no longer be installed
(if necessary) on these PCs at boot? (I don't even want Office XP
"advertised" on the PCs it was assigned to anymore, either) Since as
soon as I created the assigned package it disappears from the “Computer
Configuration” -> “Software Settings” -> “Software installation”, is the
only way to delete the “Deploy Office XP” group policy and then make a
new policy called “Deploy Office 2003” and assign the Office 2003
package to those PCs?

Steve

 

[Denis Wong @ Hong Kong]

Hi Steve,

One simple method is to move the computer objects out of the OU with the GPO
and into another OU. The installation should be uninstalled on the next
reboot.

br,
Denis

 

[Steve Stormont]

Not sure I understand what to do. The computers are in the default
"Computers" container. Do I need to make a new container, move the PCs
in question to that container, and then move them back?

Steve

 

[Ken B]

You've applied your Office XP installation policy at the domain level?

 

[Steve Stormont]

Looks like it. I think it's time to clean some things up.

So, I made an OU for our office called Columbia. Should I now just move
each of the computers from the default Computers container to the new
Columbia OU? There is no way (or is it even necessary) to make a Computers
container in the new Columbia OU? After those are all moved, then make a
new Group Policy at the Columbia OU level, right?

Thanks for the help

Steve

 

[Steve Stormont]

OK, I'm really trying to clean this thing up and need some suggestions.
Here is how it was:

We have two offices, 15 miles apart. (Columbia and Laurel) One office
has 150 PCs and the other has 30, so we aren't talking about a huge
enterprise here.

When a computer is added to the domain it is left in the default
Computers container and is added to either the "Columbia Computers" or
"Laurel Computers" group that is also in that container. When a new user is
created, they are added to default Users container and either the "Columbia
Users" or "Laurel Users" distribution group.

We had a number of group policies that had been created at the domain
level. Depending on which office the settings in the policy applied to, we
would only allow "Read" and "Apply Policy" permissions on the security of
the policy for either the Laurel user and computer groups or the Columbia
user and computer groups. Some policies had computer settings others had
user settings which is why we would apply the different groups.

I have since made an OU called IMS. Under this OU, I made two other OUs
called Columbia and Laurel. At the IMS OU, I made a new group policy for
settings applied to both offices, but not the domain controllers (WSUS). On
the Columbia and Laurel OUs I made new policies for the settings that
correspond to that location.

I then moved the two Columbia and two Laurel groups into their new OUs.
Running GPResult on one of the PCs shows that those policies are never
applied, just the policies that are still at the domain level. I tried
gpupdate /force then rebooted but the behavior was the same. If I instead
move a specific computer and a specific user from the computer and users
containers, the policies do get applied.

Should this setup work? Is it even the ideal setup? Block inheritance
is not set anywhere. Given that the policies are applied if a specfic
computer or user is listed rather than a group, it doesn't seem like the
policies are being blocked.

Steve

 

[Denis Wong @ Hong Kong]

Hi Steve,

Yes, your new setup is the more desired way to do. Actually it is not that
good to set GPO at the domain level as the flexibility is limited. And the
default Computers container is not an OU so you cannot apply GPO on it.

The point you made it wrong is that GPO applies to machines and users, not
on the group. So you should place your macines and users in the OU linking
to the GPO, not your group.

Hope this clears your confusion.

br,
Denis

 

[Ken B]

Just to follow up to what Denis wrote...

You CAN use your security groups to filter on the security (just as you did
with your domain level based policies)... but I find it much easier to 'OU
out' the users/computers/whatever... make a separate parent OU for
"Workstations", then have 2 child OU's under that for your 2 locations.
Same with the users... I named my parent OU "Company" and have 2 locations
the users are in in their own OU's under that (NY and VA).

I hardly ever use security filtering... it's more the exception to the rule
in my environment.

hth

Ken

 

[Bruce Sanderson]

Organize your OUs according to how you want to administer things and how you
want to apply GPOs. To use GPOs effectively and simply (well, as simple as
possible), the OU structure has to be appropriate to requirements. Using
Security Filtering can be complicated becuase user accounts in particular
often end up in many groups - avoid using Security Filtering unless there is
no other effective way to do what is required.

GPOs don't apply to groups, but rather to user accounts and computer
accounts in OUs - User Configuration settings to User Accounts and Computer
Confiuguration settings to Computer Accounts.

Often, computers are administer/managed differently or by different people
than users - for example, you might want a responsible person in an office
to be able reset passwords for users in that office - after all, someone in
the same office is most likely to know the person is who they say they are
as opposed to someone in head office. On the other hand, you may want to
completely manage all the computers from head office. My experience is that
creating the OU structure with Users, Groups and Computers at the top and
offices, locations or departments under those (as appropriate), generally
works better than having the offices, locations or departments at the top
with Users, Groups and Computers below.

Create your own top level container for your OUs - this tends to make things
simpler.

e.g.
Forest
Domains
domainname
My Top Level OU
Users
Columbia
Laurel
Computers
Servers
Workstations
Desktops?
Laptops?
Groups
Workstation Administration groups
Folder access control groups
AD administration groups

You may find, for example, that you only need one OU for all workstation
computers, regardless of location. The OU strucuture needs to reflect the
way things are managed, not necessarily the organisational structure or
physical locations of things.

If the OU structure you create in the beginning doesn't seem to work well,
consider changing it - moving objects between OUs and modifying the OU
hierarchy is relatively simple - but do some planning.

You may find the "rules" at
http://members.shaw.ca/bsanders/WindowsGeneralWeb/HappyGPOs.htm of some use.

It is generally useful to add the computer account in AD before joining the
computer to the domain. That way, you put the computer account in the OU
you want it in right from the start - you don't have to move it later.
Also, any computer GPO settings will get applied to the computer
automatically when it is joined to the domain.
--
Bruce Sanderson MVP Printing
http://members.shaw.ca/bsanders

It is perfectly useless to know the right answer to the wrong question.