Why would you want to set this policy?

• In most cases, the default Group Policy setting for refresh interval is something you probably won’t want to touch.  However, if you’re in an environment where the Group Policy is changed or tweaked a lot (like a test environment), it can be helpful to get the changes to the clients without having to constantly run gpupdate.
• This setting can also be useful if you’re planning on implementing major changes to your Group Policy.  By setting the refresh interval to a lower number, you can more easily roll back changes if your end users run into problems with the new policies without having to instruct the end users to run gpupdate.

Where is the policy located?

• Computer Configuration > Administrative Templates > System > Group Policy > Group Policy refresh interval for computers

Configurable Options

• How often Group Policy is refreshed in minutes
• Random time added the refresh interval in minutes (to prevent all clients from trying to refresh Group Policy at the same time)

Supported Operating Systems/Software

• Windows 2000 and up

Gotchas and Other Considerations

• The policy only applies to computer accounts in Active Directory and does not apply to Domain Controllers.
• If you set this policy too low, I’ve seen situations where end users can see a noticeable screen flicker.  One caveat with the screen flicker is that I haven’t personally

• Part 1: Introduction – Introduction to Folder Redirection in Group Policy.
• Part 2: Setting up Your File Server – Creating a share, configuring share permissions, and configuring folder permissions on your file server.
• Part 3: Folder Permissions – Explanation of the folder permissions used for the file server that were configured in Part 2.
• Part 4: Configuring – Configuring Folder Redirection in Group Policy and the available options.
• Part 5: Best Practices – A collection of tips, tricks, and best practices to help your implementation of Folder Redirection.

• Part 1:  Planning – Planning your AppLocker deployment including how to auto-generate rule and how to audit your rules first.
• Part 2:  Best Practices – Best Practices for writing your AppLocker rules.
• Part 3:  Testing – How to test your AppLocker rules before deploying them to end users.
• Part 4:  Deployment – Deploying AppLocker to your end users.

I was actually able to get the policy to work on a laptop with a hard-wired connection and a WiFi connection.  First, I authenticated into AD (over the hard-wired connection) and clicked on the Network icon in the Notification Area.

After clicking the Network icon, I was presented with a list of wireless networks available to me.  This particular wireless network is a DLink mobile hotspot that I use when I travel for hotels that only offer Ethernet and it was not connected to an Internet connection (and therefore couldn’t get back to my AD).  The hotspot was configured as a DHCP server and was giving out IP addresses in a private range that is a completely different subnet than my home network.  In these screenshots, it is configured with WPA2, but I tried it on WPA and WEP also with the same results.

Click on the wireless network name and I’m offered a checkbox (which was automatically checked) and a Connect button.

Click the Connect button and I get:  Can’t connect to this network – Your network administrator doesn’t allow simultaneous connections to your workplace network and another network.

In this scenario, it looks like I’m falling into:  “Manual connection attempts.  When the computer is already connected to either a non-domain based network or a domain based network over Ethernet, and a user attempts to create a manual connection to an additional network in violation of this policy setting, the existing Ethernet connection is maintained and the manual connection is blocked.”  I’ll have to dig out some hardware (namely a USB Ethernet adapter and another wifi hotspot) to play around with this policy further on physical hardware since doing it in a VM seems to be problematic.

Since this is still a beta, the documentation is a bit lacking.  That said, I’m hoping the documentation that will be made available in the future is a little better than the Help box in the GPMC.  This is potentially a pretty cool feature to have if you have mobile users that have 3G/4G cards or adapters that have to worry about data caps or you’re in an environment where there are tons of WiFi signals.

On the Windows 8 front, I’ve been playing around with Windows 8 like pretty much everyone else in the IT community.  Every time I boot up a copy, I find something I haven’t noticed before.  While loading Windows 8 Server into VM, I noticed a symbol that looked like a fermata at the end of the password field when I started typing in a password.  Well, of course, my first inclination is, “what the heck is that?”  And, of course, I just kept going.  I noticed it again when the login screen came up and decided to click on it.  It looks like the fermata is actually supposed to be an eye…  clicking on it revealed my password.  Cool!  I think…

In looking through some of the new Windows 8 Group Policy, it looks like Microsoft is calling this feature “password reveal.”  Ok…  I can see where this could be useful; but, I can also see where in some environments it is a really bad idea to have this turned on. Honestly, I don’t want to know what my users are using for passwords.  From an auditing standpoint, it is better for me to not know their passwords.   Besides, we have password policies and can hopefully through training steer our users toward creating good secure passwords.

In the event you’re on the fence with this new feature like I am, there is a Group Policy setting that disables it.  In the GPMC for Windows 8, go to Computer Configuration > Administrative Templates > Windows Components > Credential User Interface > Do not display the password reveal button.  Set the policy to “Enabled” and say goodbye to the password reveal fermatas/eyes!

The setting is also available in User Configuration > Administrative Templates > Windows Components > Credential User Interface > Do not display the password reveal button, if you just want to disable the feature for a subset of your users.  Just be aware that using it on the User side won’t disable the feature on the logon screen.

Another fair word of warning, the policy specifically cites Windows 8 Consumer Preview and Internet Explorer 10 as products affected by this policy.  I’ve already tried a few different third-party applications and they did not have the password reveal fermata/eye in them.  In the event Microsoft makes this feature available to developers, it could start showing up in other applications.  If it does, I’ll re-visit this setting and see if third-party apps are compliant with the Group Policy setting.

Standard warning about disabling the update utility for 3rd party software:  You still need to update 3rd party software just like you would install monthly updates from Microsoft.  This tutorial is intended for systems administrators that are using some kind of systems management product for updating 3rd party software.  Many of the security flaws in 3rd party software can lead to malware infections and/or compromised computers.   If you disable the update notifications, you still need to keep the software up to date!

This tutorial applies to 32-bit Java running on a 64-bit Operating System.  If you’re running 32-bit Java on a 32-bit Operating System, you’ll need a different tutorial.

x86 Java stores the setting that you need to disable updates in HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\JavaSoft\Java Update\Policy in 64-bit Windows.  The registry entry is named EnableJavaUpdate and is a  DWORD value that defaults to 1 for the update functionality to be enabled.  Setting the value to 0 disables updates.  Here’s what it looks like in the Registry with updates enabled:

You could set this manually, but there’s actually a much easier way to do this in Group Policy.  First off you’ll need a Group Policy Object (GPO) that applies to your computers that need to have the updater disabled.  In my example, it is an empty GPO, but there’s no reason why you can’t add this to an existing GPO.

In your GPO, go to Computer Configuration >  Preferences > Windows Settings > Registry.  Right-click and choose New > Registry Item.

If you have the 32-bit Java installed on your management station (running 64-bit Windows), you can browse the registry to the setting you’ll be changing.  (If you don’t, you can skip the next couple of steps and copy the entry manually.)  In the Window that opens, click the “…” button next to Key Path.

Browse down to HKEY_LOCAL_MACHINE > SOFTWARE > Wow6432JavaSoft > Java Update > Policy.   In the bottom window, you should see EnableJavaUpdate.  Click on it and then click Select.

When you’re taken back to the last window, it should look something like the screenshot below.   If you didn’t have Java installed on your management station, you can enter the following:

Action:  Update
Hive:  HKEY_LOCAL_MACHINE
Key Path:  SOFTWARE\Wow6432Node\JavaSoft\Java Update\Policy
Value name:  EnableJavaUpdate
Value type:  REG_DWORD
Value data:  00000000  (that’s 8 zero’s)

When you click OK, it should look something like this in the Group Policy Management Editor:

All that is left is to let Group Policy refresh on your test systems (or you can run a gpupdate.exe manually).

Let me start with my standard warning about disabling the update utility for 3rd party software:  You still need to update 3rd party software just like you would install monthly updates from Microsoft.  This tutorial is intended for systems administrators that are using some kind of systems management product for updating 3rd party software.  Many of the security flaws in 3rd party software can lead to malware infections and/or compromised computers.   If you disable the update notifications, you still need to keep the software up to date!

This tutorial applies to 32-bit Java running on a 32-bit Operating System or 64-bit Java running on 64-bit Operating System.  If you’re running 32-bit Java on a 64-bit Operating System, there’s a different setting that you’ll need.

Disabling the Java update notifications is actually pretty easy.  There’s a registry setting in HKEY_LOCAL_MACHINE that will allow you to completely disable both update notifications and the update functionality.  The full path of the key is HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Update\Policy\.  The registry entry is named EnableJavaUpdate and is a  DWORD value that defaults to 1 for the update functionality to be enabled.  Setting the value to 0 disables updates.  Here’s what it looks like in the Registry with updates enabled:

You could set this manually, but there’s actually a much easier way to do this in Group Policy.  First off you’ll need a Group Policy Object (GPO) that applies to your computers that need to have the updater disabled.  In my example, it is an empty GPO, but there’s no reason why you can’t add this to an existing GPO.

In your GPO, go to Computer Configuration >  Preferences > Windows Settings > Registry.  Right-click and choose New > Registry Item.

If you have Java installed on your management station, you can browse the registry to the setting you’ll be changing.  (If you don’t, you can skip the next couple of steps and copy the entry manually.)  In the Window that opens, click the “…” button next to Key Path.

Browse down to HKEY_LOCAL_MACHINE > SOFTWARE > JavaSoft > Java Update.  In the bottom window, you should see EnableJavaUpdate.  Click on it and then click Select.

When you’re taken back to the last window, it should look something like the screenshot below.   If you didn’t have Java installed on your management station, you can enter the following:

Action:  Update
Hive:  HKEY_LOCAL_MACHINE
Key Path:  SOFTWARE\JavaSoft\Java Update\Policy
Value name:  EnableJavaUpdate
Value type:  REG_DWORD
Value data:  00000000  (that’s 8 zero’s)

 When you click OK, it should look something like this in the Group Policy Management Editor:

All that is left is to let Group Policy refresh on your test systems (or you can run a gpupdate.exe manually).  If you open the Registry Editor, you should see the setting changed:

If you’re on a 32-bit OS, you can go to the Control Panel, run the Java Control Panel tool, and you’ll see that the Update tab is now gone.  (For some reason, the 64-bit version of Java on a 64-bit OS doesn’t have the Update tab.)

• Part 1:  User Communication
• Part 2:  Test and Deploy
• Part 3:  Group Policy not applied?
• Part 4:  Client Problems
  
• Part 5:  Active Directory Problems
• Part 6:  Common Problems

In your GPO, go to Computer Configuration > Policies > Administrative Templates > System > User Profiles > Delete user profiles older than a specified number of days on system restart.  Click Enabled and set the number of days you want to wait before deleting old profiles.

There are two things you’ll need to keep in mind:  First off, the deletion process happens on reboot.  Assuming you’re patching regularly, this shouldn’t be a problem unless you’re dealing with a really high volume of logins and have this set to a very low number.  Second, I’ve had a few situations where the user’s profile was deleted, but the C:\Users\username folder stayed behind.  The next time the user logged into the computer, they got a new profile folder at C:\Users\username.domain.