Previously the common and accepted way to add a policy template into a new group policy was to do it from within the policy itself, that would be done by right clicking on Administrative Templates and then adding it from there, picking the correct template you were wanting to add, as below;
Though in a domain environment, you really should be looking at doing this centrally by creating a central policy store. Doing this has a few advantages, such as all the policy template files being replicated round all servers either via FRS or DFSR, and only having one place to go to update or add templates, making future management simpler. Microsoft have all the details, but it’s a fairly simple process;
Create the root folder for the central store %systemroot%\sysvol\domain\policies\PolicyDefinitions on your domain controller.
Create a subfolder of %systemroot%\sysvol\domain\policies\PolicyDefinitions for each language your Group Policy administrators will use.
Note: Each subfolder is named after the appropriate ISO-style Language name, for example, to create a subfolder for U.S. English, create the subfolder: %systemroot%\sysvol\domain\policies\PolicyDefinitions\EN-US
This should make your life a little easier when it comes to managing policy templates.
So, you’re managing a Windows estate and you’re in the process of updating Internet Explorer versions that you’ve managed via Group Policy. At some point you’re going to have multiple versions of Internet Explorer out in the wild and need to manage the settings for them both. As you should know by now, Internet Explorer maintenance settings have been deprecated in favour of Group Policy preferences.
The first thing to note is that even if you download the Group Policy templates for IE11 and install them correctly, you wont see an option for IE11, just IE10 and earlier.
Not to worry though, IE10 settings will apply just fine to IE11 and that is the desired behaviour. So, now you know how to configure settings for IE11, you might wonder how preferences for different versions of IE in the same policy would interact on the client machine. Well in the setup I looked at this had previously been done using item level targeting, which is in the common tab of the policy;
The targeting was looking into the registry and checking for specific version strings which would only have the policy apply where the registry strings matched what was being checked;
Now, while the above method would work it’s unnecessary. When you create a new setting within the policy, you’ll see some Item-level targeting is already put in place by Microsoft to ensure the settings only get applied to the right version IE on the client. The version of the IExplore.exe process running on the client machine is checked and then that is used to determine which IE settings to deploy from the GPO. So in my environment, as you can see below the settings would only apply to specific IE versions;
The XML file already contains all it needs to look for specific versions of IE, and as a result the various policies can co-exist with each other.
In short, the item level targeting is done for you, no need to add any more targeting unless you need to filter things down further.
I came across a problem today with a rather aged Server 2003 R2 server. I rebooted it as part of some troubleshooting, and after the reboot found I was unable to connect to the server via RDP. So, I jumped on the VM console to check various things, the Terminal Services service was started, but I did force a stop of this and start it again. Checked over the registry to ensure the listening port hadn’t been changed for any reason. Checked the terminal services configuration to ensure the connection wasn’t disabled and there were no strange limits imposed on the connection, but all looked normal. I did try disabling and re-enabling the connection, but still no luck. When I did a netstat -ao and looked for anything listening on 3389, there was nothing at all listening, no Terminal Services or any conflicting service was listening on port 3389.
In the end, after a bit of a search on Google and a bit of checking, one suggestion mentioned was to re-register the Terminal Services DLL. So using the following command regsvr32 remotepg.dll I tried this and the registration failed. Tried to un-register it first with regsvr32 /u remotepg.dll but again this failed. So, I came to the conclusion there might be a problem with the DLL. So, I copied the DLL from another working machine, un-registered and re-registered the DLL again, which succeeded this time round. Then after a reboot, I was hopeful, but still no joy. Final, checking the Terminal Services configuration again I noticed that now the connection was disabled, right clicking and going to All Tasks and enabling the connection, I was then able to connect via RDP. Success
After switching to lighttpd away from Apache I was pretty pleased with the whole process, everything seemed to be working fine, with the exception of my permalink structure. Bad news, until I came across this posting on Tenable Tech Tips.
Basically, once mod_rewrite is enabled on the lighttpd server, which is done by adding the following line to the lighttpd.conf file;
server.modules += ("mod_rewrite")
Use the following re-write rule, which covers off permalinks and exclusions for other static files. the final code to insert should look like the below, with the obvious changes for your host;
I found today I needed to check my SMS message centre settings on my OnePlus One, but wasn’t able to find the option anywhere in the standard settings.
The solution was to use the dialer, enter *#*#4636#*#* and then this takes you through to a testing information screen with various information menus. Under the “Phone Info” menu, down the bottom of the page, you should see the SMS Message Centre options, labeled “SMSC”. From here you can update the settings and refresh them if you ever have any issues sending SMS messages. Obviously the specific number to enter will depend on your mobile operator.
I didn’t even know this setting existed as an option within Group Policy, but then again, Group Policy is a bit of a beast at the best of times.
So, the PDC emulator is responsible in the domain for handling password replication to other domain controllers, a password change occurs on the PDC and this is then replicated out to all other domian controllers. But what if you have a large infrastructure and the password change hasn’t replicated out yet to the domain controller being used by a client to authenticate? Well there’s a policy setting you can apply to your domain controllers, that forces them to check with the PDC in the event they deny a logon request due to a bad password. The setting is called “Contact PDC on logon failure” and it is briefly detailed on TechNet, and within the Group Policy editor, lives at the below location;