Tag Archives: computer policy

Windows – Forcing Domain Group Policy

Posted on by
1

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

VMware View – Using Persona Management

Posted on by

KB ID 0000615 

Problem

Persona Management, is the VMware version of “Roaming Profiles” and “Redirected Folders” rolled into one. Though the redirected folders bit is a lot easier to set up and less problematic than the Microsoft Folder Redirection policy.

Its handy if you using floating pools but still want your users to have a persistent user interface. Having these files centrally makes them easier to backup, and the more your users can customise their desktops and settings the better their level of equipment husbandry.

Solution

Create a “Roaming Profile” Network share with the correct permissions

1. On a network accessible server, create a folder and set the SHARE permissions as follows;

Share Permissions

Everyone = Read. Domain Users = Full Control.

Note: You may also want to DISABLE Caching on this folder.

2. Stop inheritable permissions from propagating to the folders and set the security permissions as follows;

Security / NTFS Permissions

Creator Owner (Subfolders and Files Only) = Full Control. Domain Users (This folder Only) = List Folder/Read Data and Create Folders/Append Data. System (This Folder, Subfolders and files) = Full Control. Creator Owner (Subfolders and Files Only) = Full Control. Everyone = No Permissions.

Note: I’m using domain users, you might have a different security group that you want to substitute.

3. Make sure that the machines that you will be using as view targets, have the View Persona Management option selected (this is selected by default).

Configure Windows 7 to be a VMware View Desktop

4. You need to get the administrative template for Persona Management. You will find it on your VMware Connection Server in the following location;

[box] C:Program FilesVMwareVMware ViewServerextrasGroupPolicyFiles [/box]

Locate the ViewPM.adm file and copy it to a domain controller.

5. Create a new group policy that is linked to the OU containing your View machines.

6. Edit the policy > Expand Computer Configuration > Policies >Administrative Templates > Right Click > add/Remove Administrative Temple > Add in the ViewPM.adm template.

7. Navigate to;

[box] Computer Configuration > Polices > Administrative Templates > Classic Administrative Templates > VMware View Agent Configuration > Persona Management [/box]

8. In the roaming and Synchronisation Section > Manage user persona > Set to Enabled > Next Setting.

9. Enable > Enter the shared folder you created earlier > Next Setting.

10. Enabled (to remove local cached copies of the profile).

11. Enabled to roam the local folder > That’s all I’m going to configure in this branch of the policy.

Persona Management Folder Redirection

12. Navigate to;

[box] Computer Configuration > Polices > Administrative Templates > Classic Administrative Templates > VMware View Agent Configuration > Persona Management > Folder Redirection [/box]

Here you will find the folders that can be redirected to a central location.

13. For example, here I’m redirecting the users “My Documents” folder.

14. And their “My Pictures” folder.

15. Make sure you have a pool created, and your users are have an ‘entitlement’ to them. These machines will also HAVE TO be in the OU your policy is applying to.

Creating a ‘Manual Pool’ and Connecting a View Client

Deploying Linked Clone View Desktops

16. Now when your users connect to their View Desktops.

17. Their user profile will be persistent.

18. Because their settings are stored in your profile shared folder.

Note: Persona Management will store the profile in username.domainname format. The reason there is a V2 on the end of it, denotes the profile is for Windows 7 or Vista. If users swap between these OS’s and any older Windows OS’s, then they will get a separate profile for those as well. If this is the case rely on the folder redirection rather than the profile.

Related Articles, References, Credits, or External Links

NA

RDS Server – Remove the Shutdown Command

Posted on by

KB ID 0000499 

Problem

I’m surprised that when you make a server a Terminal Services Server / Remote Desktop Services Server, that this does not get applied from an administrative template anyway, but it does not.

Why would you want to do this? Well users are used to hitting Start > Shutdown, when they are finished working, which is fine, unless they are in a terminal session with 500 other users and they’ve just issued a shutdown command to the server!

Solution

The simplest way to do this is run gpedit.msc on the server itself and remove shutdown through local group policy, but a far more elegant solution is create a domain group policy for the TS Server(s).

1. On a domain controller,  launch the “Group Policy Management Console”. Create a policy, and link it to the OU that contains the Terminal Servers, you want to enforce the policy on, (Or edit an existing policy linked toy them).

2. Now remove the shutdown is a USER policy, and this is a COMPUTER policy we are writing, so it wont work unless we turn on “Loopback processing”. Navigate to Computer Configuration > Administrative Templates > System > Group Policy > User Group Policy loopback processing. (Note: On 2016 It will be called, ‘Configure user Group Policy loopback processing mode’.)

3. In most cases you will already have user policies applied to your users, if so you will want to “Merge” this with them rather than replace them > Apply > OK.

4. Now to remove the Shutdown command. Navigate to User Configuration > Administrative Templates > Start Menu and Taskbar > Remove and prevent access to the Shut Down, Restart, Sleep, and Hibernate Commands.

5. Enable > Apply > OK.

6. Then either reboot the TS Server(s), wait a couple of hours or run “gpupdate /force” on them.

 

Related Articles, References, Credits, or External Links

NA

Deploying Printers with Group Policy Preferences

Posted on by

KB ID 0000492

Problem

I’ve touched on this briefly in KB0000389, I suggest you read through that first so you understand what the requirements are to deploy a GPP instead of the GPO’s you are probably used to.

Solution

1. First thing to do is install the printer that needs deploying on a print server. Make sure if your clients are NOT x64 bit that you also add the x86 drivers for your clients to use.

How to tell if a machine is x86 (32 bit) or x64 (64 bit).

2. The following is a “Gotcha” (especially on HP printers), on the Printer Properties page, General tab > Select “Print Processor” > Ensure it’s set to winprint and RAW.

3. On a domain controller, Start > administrative tools > Group Policy Editor > Either edit an existing policy or create a new one (Remember its 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).

4. Give the policy a sensible name.

5. Edit the policy you have just created.

6. Navigate to > Computer Configuration > Preferences > Control Panel Settings > Printers > In the right hand window, right click > New > TCP/IP Printer.

7. Select Create > I prefer to use the IP address of the printer but you can use the DNS name if you wish > The Local Name is what the client will see > Enter the Path to the printer (In UNC format) > You can also enter a location and comment if you wish > Apply > OK.

8. All being well you should see the printer listed.

9. Now for another “Gotcha” in the same policy navigate to > Computer Configuration > Policies > Administrative Templates > Printers > Locate the “Point and Print Restrictions” policy.

10. Change the settings for this policy so that it is disabled.

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

 

Related Articles, References, Credits, or External Links

Server 2008 Group Policy Preferences and Client Side Extensions