Windows – Forcing Domain Group Policy

KB ID 0001282

Problem

I’ve written hundreds of posts about doing things with group policies. Every time I finish one, I write a couple of paragraphs on how long to wait, or how to force the policy etc. So I’ve finally got round to writing a post I can simply reference!

How Long Before Group Policy Changes Are Applied?

This is something that hasn’t changed since I was doing Windows 2000 exams 🙂 The default interval between policies being applied is 90 minutes, plus or minus a figure between 0 and 30 minutes. (This avoids all user and computer policies being seen and applied at the same time. So between 60 minutes and 120 minutes if you are going to wait.

Now you can change this interval with group policy;

[box]

User Configuration > Administrative Templates > System > Group Policy > Group Policy refresh interval for users
Computer Configuration > Administrative Templates > System > Group Policy > Group Policy refresh interval for users

[/box]

As you can see, you can change the interval up to 64,800 seconds (45 days). If you set it to ‘0’ the policy updates every 7 seconds (NEVER DO THIS!) unless you’re on a test bench with a couple of computers! Personally I’ve never needed to mess around with these settings.

Solution

Force Group Policy Update From GPMC

If you have Windows 2012 server with the group policy management console installed, you can force a group policy refresh on an OU in Active Directory.

Either right click the OU, and select ‘Group Policy Update..’ (or from the Action menu) > Yes.

Some will fail, they might not be turned on, or (like some below,) they might be linux machines.

Manually Force a Group Policy Update on a Single Host

While testing new policies this command is your friend, it gives you a chance to test the result on a client instantly, (as soon as policy editing is finished). By opening an administrative command window, and running the following command.

[box]gpupdate /force[/box]

Note: Some policies require a log off/log on, or even a reboot, you should be told this after running gpupdate.

Force Group Policy Update with PowerShell

You can also get single/multiple machines/users to update their policies using PowerShell. For this to work you need Server 2012 and at least Windows 8 clients. You also need to make some changes to the machines firewalls. Luckily you can also do that with group policy, and Microsoft have already written the policy for you, (it’s in starter policies).

Within the Group Policy Management Console > Locate Stater GPOs > Group Policy Remote Update Firewall Ports > New GPO From Starter GPO > Give the new policy a name.

Link that new policy to your user/computer organisational units (as required).

You can now use the ‘Invoke-Gpupdate‘ commandlet, here I’m applying the update to the ‘Servers’ OU.

[box]get-adcomputer -SearchBase “OU=Servers,OU=PNL,DC=pnl,DC=com” -Filter * | %{invoke-gpupdate -Computer $_.Name -RandomDelayInMinute 0; “Refreshing host $_.”}
[/box]

Warning: This displays output on the affected machines, and might start some users ringing the help desk!

See What Group Policies are Being Applied

Forcing them is one thing, proving they actually get to the target computers is something else. For peace of mind, and troubleshooting, it helps to see what policies have filtered down to the computers and users.

The easiest way, is to open an administrative command window, and run the following command;

[box]gpresult -R[/box]

Or to see things a little more ‘granularly’. Windows Key + R > mmc {enter} > File Add/Remove  Snap-In > Resultant Set of Policy > Add > OK.

Generate RSoP Data > Follow the Wizard.

When complete it will show you the ‘sum total’ of all policies being applied – it can also show you any problems that are occurring. The next best place for troubleshooting group policies is the Event Viewer on the target machine.

Related Articles, References, Credits, or External Links

NA

Deploy the Trend Worry Free Business Client via Group Policy

KB ID 0000491

Problem

Trend Worry Free is a nice product, though to deploy the client software out to your machines, you need them to be switched on, have the firewalls off, and the remote registry service running. You can of course connect the clients to the web portal and install the client on a machine by machine basis, (default https://servername:4343), but if you are rolling out a lot of machines this can get tedious.

So you can either script the install or use Group Policies.

Solution

1. Firstly you need to create the install file, on the server that Worry Free is installed navigate to;

[box]

Worry Free Version 7

C:\Program Files (x86)\Trend Micro\Security Server\Admin Utility Client Packager

Worry Free Version 8

C:\Program Files (x86)\Trend Micro\Security Server\PCCSRV\Admin Utility ClientPackager\

[/box]

Locate the ClnPack.exe file and run it.

2. We want a setup package, select your platform, I want it to install silently and NOT to do a prescan. Save the output file somewhere you can find it and click “Create”.

3. Note: If have x64 bit clients that you are also going to deploy software to, you will need to repeat the process and create another package for x64 bit installations as well.

How to Tell if Windows is 32 or 64 bit

You can use a WMI filter to make sure the right policies apply to the right clients;

Using 32 and 64 Bit WMI Filters For Group Policy

4. After a while it should say it was successful, close down the client packager.

5. Create a network share and allow the “Everyone Group” read access to it, then copy the setup file you created above into this share.

6. On a domain controller, Start > Administrative tools > Group Policy Editor > Either edit an existing policy or create a new one. (Remember it’s a computer policy you need to link it to something with computers in it, if you link it to a users OU nothing will happen).

Navigate to:

[box] Computer Configuration > Policies > Software installation [/box]

And create a new package.

7. Browse to the UNC path of the setup file DO NOT browse to the local drive letter!

8. Set as “Assigned” > OK.

9. Make Sure: That if you have x64 bit clients, you open the advanced properties of this package, and remove the option to deploy this software to x64 bit clients.

10. Repeat the process for the x64 bit client if you also have x64 bit machines.

11. Close the policy and group policy editor window.

12.  Then either reboot the clients, wait a couple of hours, or manually run “gpupdate /force” on them.

Related Articles, References, Credits, or External Links

Original article written 11/08/11

Public Folder Migration Exchange 2003 to 2010

KB ID 0000426 

Problem

I’ve already written at length about migrating from Exchange 2003 to 2010, I was doing a migration this week and migrating the public folders was proving to be a pain.

If you have multiple public folders within public folders then setting up replication can be a nightmare, as the replication settings don’t get passed down to the child object.

Normally you could use PFDAdmin and this would do it for you, or use the Exchange ExFolder tool, or even the powershell scripts included with Exchange 2010 (like AddReplicatoPFRecursive.ps1). But sadly all these failed for me today.

To use the Exchange 2010 Scripts click here.

In the end, with the aid of third line support at Microsoft, it was fixed using a feature of Exchange 2003 that I NEVER KNEW was there 🙂

Solution

1. The bad news is you still have to add the new Exchange 2010 server as a replica on the top level folder. (Right click > Properties > Replication Tab > Add > Add in the new server > Set the interval to always run > priority to urgent (unless you have a LOT! then choose Normal) > Apply.

Update: Eagle eyed visitor Brian Morphey, mailed me to point out that in my diagram all the folders are under the Exchange 2010 Administrative group, How did they get there? You need to use Exchange system Manager to create a public folder group in the new administrative group then simply DRAG the public folder group from the old admin group to the new one.

2. Right click the folder again > All Tasks > Manage Settings.

3. Select “Modify lists of replica servers” > Next.

4. Add servers > Next.

5. Add in BOTH the 2003 server AND the 2010 server > Next.

6. Finish.

7. It will now run through all the sub folders and apply the same replication settings on all of them, this can take a while depending on the number of folders.

8. Go to the Exchange 2010 Server and open the Public Folder Management console, right click Public Folder {your server name} > Update Hierarchy.

9. Repeat the above, but this time select “Refresh”.

10. Finally to speed things along, you can right click each folder and select “Update Content”.

11. Now wait! It can take a while till replication is complete.

Removing Public Folder Replicas

Once All the data has replicated across you can remove the 2003 replica by doing the reverse.

1. Right click the public folder > All Tasks > Manage Settings > Next > Modify List of replica servers > Next.

2. Remove servers> Next > Tick the server you want to REMOVE the replica from > Next.

3. Finish > Depending on the amount of data it may take a while.

Migrating Public Folders with Exchange 2010 Scripts

Step 1 Set up Public Folder Replication to Exchange 2010

On the Exchange 2010 Server open the Exchange Management Shell and execute the following three commands;

[box]
CD “C:Program FilesMicrosoftExchange ServerV14Scripts”
.AddReplicaToPFRecursive.ps1 -TopPublicFolder “” -ServerToAdd “EX-2010.petenetlive.com”

Update-PublicFolderHierarchy -Server “EX-2010.petenetlive.com”
[/box]

Step 2 Once the Replication Has occurred

Warning: Check that replication is complete before you do this!

Check replication with a “Get-PublicFolderStatistics ” command, once you are happy, run the following two commands;

[box]CD “C:Program FilesMicrosoftExchange ServerV14Scripts”
.MoveAllReplicas.ps1 -Server “EX-2003.petenetlive.com” -NewServer “EX-2010.petenetlive.com”[/box]

Related Articles, References, Credits, or External Links

Thanks to Brian Morphey for the feedback.