This is Paul Fragale, coming to you from my little corner of the world. With the launch of Windows Server 2008, there have been several cases around Terminal Server and Terminal Server License Server. I would like to take a moment to review with you some common steps that can help you resolve these issues.
The first case:
Introducing a Windows 2008 Terminal Server into your existing Windows 2003 Environment requires a little preparation. The first main point is that a Windows Server 2008 Terminal Server can only talk to a Windows 2008 License Server. (Additional information can be found at http://technet.microsoft.com/en-us/library/cc770371.aspx) There are two ways to set up the environment to handle this requirement:
- The first is to upgrade your existing license server to 2008. You will need to have access to all your license packs before doing this.
- The second is to add an additional terminal license server (has to be Windows 2008, remember) to your environment. Then configure the terminal servers to point directly to the correct license server. This can be accomplished by changing the configuration of discovery in the “Terminal Services Configuration” tool.
The second case:
Limiting your Client Access Licenses (CALs) issuance is a frequent concern. With the auto-discovery process any Terminal Server can search Active Directory for a license server. If it finds one, it can then use the TSLS to issue licenses, thereby possibly depleting your license pool inadvertently. To prevent this, Microsoft has introduced a new group called “Terminal Server Computers”. This group allows you to configure what servers the license server is allowed to talk to. It works in conjunction with the “License server security group” Group policy found in the following location:
Computer Configuration\Administrative Templates\Windows Components\Terminal Services\TS Licensing.
In Windows 2008, we have found that it is a good idea to add all your Terminal Servers to this group when the License server is Windows 2008. A couple of symptoms that people have reported are the following:
- Windows Terminal Servers are not receiving new CALs from the recently upgrade Windows 2008 Terminal License server.
- My Windows 2008 Terminal Server is only getting temporary licenses.
Once you have added the servers to the “Terminal Server Computers” group, the server will start communicating and receiving licenses from the TSL. The one catch is that the server has to have already discovered the license server.
The third case:
Upon installing a Windows 2008 TSL, you may find the following event in the System event log:
| Event ID: 8195
Task Category: None
Level: Warning
Keywords: Classic
User: N/A
Computer: tsl.alpineskihouse.com
Description:
The computer account for the Terminal Services license server could not be added to the Terminal Server License Servers group in Active Directory Domain Services during the installation of TS Licensing. The action failed with Win32 error code 0x80072037. |
This event occurs in the following situations:
- You have a Windows 2000 Active Directory domain with either all the
domain controllers are Windows 2000, or at least the PDC Emulator is still running
on a Windows 2000 domain controller. When this is the case, the "Terminal Server
License Severs" group does not exist in the "Built-in" container. Look for the
existence of this group. If it does not exist, you need to move the PDC Emulator
role over to a Windows Server 2003 domain controller (or higher) and keep it
there.
- The "Terminal Server License Servers" group does exist in the "Built-in"
container, but when the License Server installation happens it connected to a
Windows 2000 domain controller. During the installation and running of the license
server it must only connect / communicate with a Windows Server 2003 (or higher)
domain controller for it to function properly.
(I would like to thank Rob Greene for providing this third piece of information.)
So hopefully this gives you a little insight on troubleshooting your own Terminal Server License Server issues.
Until next time,
-Paul Fragale
Ned here. For all of our bilingual German readers, I wanted to point out that the Microsoft Germany DS support folks also have their own excellent blog:
Aktives Verzeichnis - http://blogs.technet.com/deds/
Be sure to add them to your feed reader of choice. Barabara, Fabian, and Rol write excellent stuff. For example, their latest post covers improving service reliability and performance by reconfiguring Kerberos PAC validation. And if your German is a bit rusty, you can use Windows Live Translator to convert it - here it is in English.
- Ned Pyle
Ned here again. A few months ago Mark Aggar, Pat Stemen, and Michael Walsh wrote an excellent TechNet Magazine article on using group policy to save power. This article gives specific examples as well as fully documents all 35 power management settings covered in Vista. I wanted to make sure our ASKDS readers hadn't missed this:
Sustainable Computing Conserving Energy with Group Policy
There are also links to some excellent additional resources included that cover energy efficiency improvements in Vista; make sure to follow them once you finish reading. For example, from the Windows Vista Energy Conservation 'Financial Impact' section, if we calculate (at July 2006 US average energy cost of $0.0931USD per kWh) power savings for just enforcing Sleep settings on PC's:
Annual Per-PC Power Cost Savings Using Sleep (Typical Pentium 4 PC with 17-inch CRT)
760.14 kWh x $0.0931 = $70.77
Annual Per-PC Power Cost Savings Using Sleep (Typical Pentium 4 PC with 17-inch LCD)
597.52 kWh x $0.0931 = $55.63
If you had only 1000 PC's you'd be saving $70,700USD annually. Not to mention that energy costs have climbed significantly since this whitepaper was created (in fact Electric Power Monthly currently puts them at $0.1044USD year to date 2008). The power draw of more advanced chipsets is always on the increase, naturally.
And not only is power conservation good for your hardware and your bottom line, but it helps your fellow citizens and your planet.
- Ned Pyle
“I don’t want my users copying data to removable drives. How can I prevent this?”
It’s a common question asked to our team. Removable drives are widespread. Current mobile devices can now store up to 8 GB of data on a micro-SD card, which is no bigger than your thumb nail. Eight gigabytes is a huge amount of data and it could be your company’s Intellectual Property (IP) going out the door. There is a need to protect your company’s sensitive information from being transferred to removable storage devices; Group Policy in Windows Server 2008 and Windows Vista can help you.
You can control access to six removable storage categories (actually seven but the seventh category controls access to ALL removable storage devices). These categories include CD and DVD, Floppy Drives, Removable Disks, Tape Drives, and WPD devices.
Figure 1 Removable Storage Policy Settings
Today’s computers usually do not included a floppy drives because the amount of data that fits on a floppy disk seems trivial in the age of one terabyte drives—regardless, you can restrict access to floppy drives, which includes USB floppy drives. Removable drives included classic USB thumb drives. WPD devices include media players, cell phones, CE devices, and some auxiliary displays. There is a custom category that allows you to identify the unique identifier of a device and control access of that device based on the unique ID.
Each device category provides two types of access control—deny read and deny write. These policy settings apply to Windows Vista or later (to included Windows Server 2008) and can co-exist in GPOs applying to clients earlier than Windows Vista; however these older operating systems ignore the policy settings.
You can find these policies under the Removable Storage Access category, under User or Computer Configuration\Policies\System\Removable Storage Access
These policy settings change the security descriptor on the removable objects. Changing the security descriptor requires a computer reboot. Window's does not reboot the computer when the policy changes these security descriptors. However, Removable Storage provides a policy setting to which you can enable to force a reboot. Enable the Time (in seconds) to force reboot policy setting and provided value (in seconds) for which Windows waits before rebooting the computer to apply the new security descriptors for removal drives.
Figure 2 Removable Storage Reboot Policy
So, keep your Intellectual Property secure by controlling access to removable storage devices. Delegate write permissions to a limited user set, or limit removable storage write access to a single workstation. You can do your part to keep your company's sensitive data where it belongs.
- Mike Stephens
Craig here again. Let’s take a look at a specific flavor of 1085 event, and its equivalent on Vista/2008, event 7016. The 1085 would show up in the Application log on XP/2003. The 7016 would show up in the Group Policy operational log on Vista/2008 (Event Viewer\Applications and Services Logs\Microsoft\Windows\Group Policy\Operational).
Event Type: Error
Event Source: Userenv
Event Category: None
Event ID: 1085
Date: 7/29/2008
Time: 11:03:23 AM
User: NT AUTHORITY\SYSTEM
Computer: M1
Description:
The Group Policy client-side extension Internet Explorer Zonemapping failed to
execute. Please look for any errors reported earlier by that extension.
Log Name: Microsoft-Windows-GroupPolicy/Operational
Source: Microsoft-Windows-GroupPolicy
Date: 7/29/2008 11:39:53 AM
Event ID: 7016
Task Category: None
Level: Error
Keywords:
User: SYSTEM
Computer: M7.contoso.com
Description:
Completed Internet Explorer Zonemapping Extension Processing in 31 milliseconds.
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Microsoft-Windows-GroupPolicy"
Guid="{aea1b4fa-97d1-45f2-a64c-4d69fffd92c9}" />
<EventID>7016</EventID>
<Version>0</Version>
<Level>2</Level>
<Task>0</Task>
<Opcode>2</Opcode>
<Keywords>0x4000000000000000</Keywords>
<TimeCreated SystemTime="2008-07-29T15:39:53.866Z" />
<EventRecordID>6128</EventRecordID>
<Correlation ActivityID="{917B65C2-7289-4E9C-8CE0-2364319F6D66}" />
<Execution ProcessID="1092" ThreadID="2332" />
<Channel>Microsoft-Windows-GroupPolicy/Operational</Channel>
<Computer>M7.contoso.com</Computer>
<Security UserID="S-1-5-18" />
</System>
<EventData>
<Data Name="CSEElaspedTimeInMilliSeconds">31</Data>
<Data Name="ErrorCode">87</Data>
<Data Name="CSEExtensionName">Internet Explorer Zonemapping</Data>
<Data Name="CSEExtensionId">{4CFB60C1-FAA6-47F1-89AA-0B18730C9FD3}</Data>
</EventData>
</Event>
The 1085 event doesn’t give us the error code. In Vista/2008, the error code shows up on the Details tab of the 7016 event.
To view the error code on XP/2003, we need to enable Userenv logging (KB article 221833). Once you’ve enabled Userenv logging and run gpupdate /force, take a look at the %windir%\debug\usermode\userenv.log.
If you do a CTRL+F ( Edit | Find) in Notepad for the text string ProcessGPOList: Extension Internet Explorer Zonemapping returned you’ll jump down to the interesting part.
ProcessGPOList: Extension Internet Explorer Zonemapping returned 0x57.
A little Notepad trivia for you – you can view the current line number or go to a different one by using CTRL+G (Edit | Go To…), but that only works if you have Word Wrap disabled (Format | Word Wrap).
The 0x in 0x57 tell us it is a hexadecimal number. 57 hex equals 87 decimal. So the return code in the Userenv.log on XP/2003 is really the same as the error code in the 7016 on Vista/2008. The 7016 is just giving it to us in decimal instead of hex. To map the 0x57 (81) to an error string, we can download Err.exe. Err will accept the decorated hex (0x57) or decimal (81) as input. You can also pull these up on the Win32 Error Codes page on MSDN.
C:\err 0x57
# for hex 0x57 / decimal 87 :
XNS_INTERNAL_ERROR bugcodes.h
MSG_E_BAD_DEFAULT_CA_XCHG_CSP certlog.mc
# Certificate Services could not use the default provider for
# encryption keys. %1
LLC_STATUS_INADEQUATE_LINKS dlcapi.h
NMERR_FRAME_HAS_NO_CAPTURE netmon.h
ERROR_INVALID_PARAMETER winerror.h
# The parameter is incorrect.
LDAP_FILTER_ERROR winldap.h
# 6 matches found for "0x57"
Ok, so we’ve got an invalid parameter somewhere. Let’s go ahead and first find the Group Policy object (GPO) that is causing the pain. On Vista/2008, it is as easy as looking on the General tab of the 4016 event that will come right before the 7016 error event. In the example below, the admin has deviated from best practices, so instead of a helpful name such as Site to Zone Assignment List GPO, it is named something less informative.
On XP/2003 we don’t have this nice 4016 event to tell us the name of the offending GPO. But almost as easily we can use Rsop.msc to find it. You can use Rsop.msc to find it on Vista/2008 too, but the 4016 is easier.
You can also double-click on Site to Zone Assignment List and see the GPO name on the Precedence tab.
So we know the offending GPO, and we can actually look at what it is trying to use right here in Rsop.msc by viewing the Setting tab and clicking Show.
And there is our problem - 192.168.* is not a valid value. Instead you could use 192.168.*.*.
Examples of invalid values:
192.168.*
http://*
http://contoso.*.com
Examples of valid values:
www.contoso.com
http://*.contoso.com
*://*.contoso.com
http://*.contoso.co.uk
192.168.*.*
At this point you would fire up the Group Policy Management Console (Gpmc.msc) or Active Directory Users & Computers (Dsa.msc) and make the appropriate edit to the Site to Zone Assignment List policy in the offending GPO. Site to Zone Assignment List is located under User Configuration\Administrative Templates\Windows Components\Internet Explorer\Internet Control Panel\Security Page. It is also possible you configured this in local policy, in which case you would edit it by running the Group Policy Object Editor (Gpedit.msc) on the local machine.
And that pretty much wraps it up. An event 1085 or 7016 error referencing the Internet Explorer Zonemapping client-side extension with error code 0x57 (81) can be caused by an invalid value in the Site to Zone Assignment List policy setting. But there are a few other details that may be interesting.
We saw the invalid value is visible in Rsop.msc and of course in the policy itself, but there are a few other places it shows up, namely the registry, the Userenv.log (XP/2003), the Gpsvc.log (Vista/2008), and finally the registry.pol file.
It is interesting to note that even when we are getting 1085 or 7016 errors, the invalid values will be set successfully in the registry and the Userenv.log/Gpsvc.log will reflect that.
Userenv logging has been documented for a long time in KB article 221833, but it is a bit harder to find information on GPSVC logging that is new to Vista/2008. This is mainly because the Group Policy operational log has vastly improved the ability to troubleshoot Group Policy issues without needing to view additional debug logging. But if you are curious, you can enable GPSVC logging via the registry.
Value Path: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Diagnostics
Value Name: GPSvcDebugLevel
Value Type: REG_DWORD
Value Data: 30002 (hex)
Output: %windir%\debug\usermode\gpsvc.log
In this situation, both the Userenv.log and Gpsvc.log will show us the same information with regards to the values that are configured in the Site to Zone Assignment List policy. Just do a search on the text string ListBox_Support_ZoneMapKey. Here you can see that even though the 192.168.* value is invalid; it gets set in the registry successfully.
GPSVC(444.91c) 17:03:40:02 SetRegistryValue: ListBox_Support_ZoneMapKey => 1 [OK]
GPSVC(444.91c) 17:03:40:02 SetRegistryValue: 192.168.* => 1 [OK]
The value is written to the following registry location:
HKCU\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMapKey
The registry.pol file in the GPO in Sysvol is the last place you could see those values. You can use Regview.exe to view the contents of a registry.pol file. It is a free download as part of the 2003 Resource Kit Tools, but it is also included by default now in Vista and 2008.
C:\>regview C:\WINDOWS\SYSVOL\domain\Policies\{144AF1E5-05FE-4C6D-8CB6-CBB945F23C85}\User\registry.pol
KeyName: Software\Policies\Microsoft\Windows\CurrentVersion\Internet Settings
ValueName: ListBox_Support_ZoneMapKey
ValueType: REG_DWORD
Value: 0x00000001
KeyName: Software\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMapKey
ValueName: 192.168.*
ValueType: REG_SZ
Value: 1
- Craig Landis
Hi, Ned again – and surprisingly, talking about DFSR!
From time to time a customer will ask us about the Deleted folder in a Distributed File System Replication (DFSR) content set. It never seems to have anything in it. Not to mention we have a folder called ConflictAndDeleted and there definitely are deleted files in there.
So what gives?
The Deleted folder only comes into regular use when the option 'Move deleted files to Conflict and Deleted folder' is unchecked under Advanced for a given replicated folder membership in DFSMGMT.MSC, like below:
When this is unchecked, a deleted file is no longer copied into ConflictAndDeleted, nor is the ConflictAndDeletedmanifest.xml file updated. Instead, the file on a downstream partner is temporarily moved into the Deleted folder while the DFSR database and USN are updated, then deleted directly from that folder.
Unless that checkbox was turned off and a massive quantity of deletes was processed, it's unlikely you will ever see files in that folder for more than a moment. But we do have a way to see things happening on the file system faster than a speeding bullet – Process Monitor.
If we run Process monitor on a downstream server and configure our filter to ‘path -> begins with -> the replicated folder’ we can see what goes on under the hood with minimal chaff.
Then we can just delete a file on an upstream server. Here’s what happens when I delete ‘Readme.doc’ on the upstream server and the deletion request reaches my downstream partner:
That’s kinda chaffy to read, so let’s cut to the important parts:
1. The file e:\datarf\readme.doc is moved to e:\datarf\dfsrprivate\deleted\ReadMe.doc-{AC759213-00AF-4578-9C6E-EA0764FDC9AC}-v141560
Perfmon Log entry:
"2:57:15.5042328 PM","Dfsr.exe","2260","SetRenameInformationFile","E:\DataRF\ReadMe.doc", "SUCCESS","ReplaceIfExists: True, FileName: E:\DataRF\DfsrPrivate\Deleted\ReadMe.doc-{AC759213-00AF-4578-9C6E-EA0764FDC9AC}-v141560"
(Do you remember from previous blog posts what the long GUID refers to? It’s the server that originated the deletion. The file is being mangled here with GUID and version because this is what would have been written into ConflictAndDeleted to maintain uniqueness.)
2. Then the file is deleted
Perfmon Log entry:
"2:57:15.5056190 PM","Dfsr.exe","2260","SetDispositionInformationFile", "E:\DataRF\DfsrPrivate\Deleted\ReadMe.doc-{AC759213-00AF-4578-9C6E-EA0764FDC9AC}-v141560","SUCCESS","Delete: True"
In case you’re curious, the Deleted folder cannot be… deleted. If you do so, the DFSR service will simply add it back in the next it’s restarted.
So we covered a bit of DFSR and a bit of Process Monitor. I hope you found this interesting. Perhaps in the comments section someone wants to take a guess at what the Installing folder is for?
- Ned Pyle
Hi. Jim from DS here again to show you how to quickly access the properties of your network interface cards via a custom desktop shortcut. In my previous blog post I put together a lovely “at a glance” reference to launching administrative and system tools from the command line and START – RUN. In Windows server 2008 and Windows Vista you might have noticed that it does require several extra mouse clicks to access the network properties dialog.
I recently overheard a colleague of mine raise his voice in anger, and while simultaneously shaking his fist at the sky he cried out “Why must I click four thousand times to get to this interface!?” I realized that NCPA.CPL may not be as easy to remember for others as it is for me. This (coupled with my colleague’s meltdown) compelled me to compose a quick blog on making a custom shortcut to access the network properties window.
On the desktop of your Windows Server 2008 or Windows Vista machine right click – NEW – Shortcut:
Type the path to NCPA.CPL and click next.
Type a name for the shortcut.
Click Finish.
You will now have a shortcut on the desktop which will take you directly to the network properties applet. Now you may change the icon which is currently the default for a .CPL file to an icon of your desiring.
Right Click on the new shortcut and select Properties.
Click on the Change Icon button.
This desktop shortcut can be readily deployed via group policy preferences to whichever servers or workstations you like. Please see the following blog post in regard to Group Policy Preferences - http://blogs.technet.com/askds/archive/2007/11/28/introducing-group-policy-preferences.aspx.
The shortcuts can be created for any administrative interface you or your IT department access frequently.
- Jim Tierney
Mike here again. Today I’m focusing on policy settings for the Event Logging Service.
For clarity, these settings control the Event Logging service; the service responsible for capturing and writing events throughout Windows. These policy settings do not affect the Event Viewer application.
These are some powerful policy settings that allow you to configure five settings for Application, Security, Setup, and System event logs. These categories and their policy settings are located under Computer Configuration\Policies\Administrative Templates\Windows Components\Event Log Service.
The Log File Path policy setting, when enabled, allows you to provide a specific location where the Event Log service writes its log file. You must provided path and filename when relocating where Windows writes the log file.
Next is the Maximum Log file size policy. When enabled, this policy allows you to specify the maximum size of the event log. It supports sizes between one megabyte and two terabytes and uses one-kilobyte increments.
Figure 1 Event Log Service Policy Settings
The next two policy settings are related. The Event Logging service uses the Retain old events and Backup log automatically when full policy settings when the event log reaches the maximum file size (defaults to 20 MB or the value specified in the Maximum Log size policy setting). With the Retain Old Events policy setting enabled, the Event Logging service stops writing new events to the event log when the log file reaches or exceeds the maximum value and you lose all new events. With this policy setting disabled, new events overwrite old events. When you enabling the Backup log automatically when full and the Retain old events policy settings, the Event Log service closes the current event log, renames it, and then creates a new log. The Backup log automatically when full policy setting works only when you enable Retain old events policy setting.
Figure 2 Maximum Log Size Policy Setting
The last setting and one that I think is the most beneficial is the Log Access setting. Enabling this setting allows you to enter a security descriptor for the log file. The security descriptor controls who can read, write, or clear the event log. You enter the security descriptor using Security Definition Description Language (SDDL), which is document on MSDN(http://msdn.microsoft.com/library/en-us/secauthz/security/security_descriptor_string_format.asp). Also, my esteemed colleague Jim provides a two-part blog series about SDDL (http://blogs.technet.com/askds/archive/2008/04/18/the-security-descriptor-definition-language-of-love-part-1.aspx and http://blogs.technet.com/askds/archive/2008/05/07/the-security-descriptor-definition-language-of-love-part-2.aspx).
Finally, I should mention that these new policy settings have precedence over the older Windows Server 2003 and Windows XP security policy setting that manage Event Logs. Both settings can exist in the same Group Policy object and apply only to the respective operating systems for the policy setting.
These new policy settings for the Event Logging service provide more flexibility and control from earlier versions. Using Group Policy to control where event logs are written, how large they can grow, how they are preserved, and who can manage them are key to change control and security auditing. You can implement these policy settings in your existing Group Policy objects and they will not affect operating systems earlier than Windows Vista.
- Mike Stephens
Ned here again. Adam Shepherd (one of our esteemed UK MS Consulting colleagues) wanted us to let everyone know that there is a new Directory Services Core Infrastructure presentation coming soon. You will need to register for this and it will be delivered August 21, 2008. It specifically goes into the new DS features offered in Win2008 and how they should make life better in your environment. This is technical, so bring your thinking caps. And no need for your checkbook, this is free.
UK MCS blog (linked to post)
Direct registration on Technet for the event
(And apologies for the short posting drought; there was a quantum vacation singularity - plenty more to come soon).
- Ned Pyle
Hi this is Rob again. We had a couple cases recently where PolicyMaker settings were not applying to computer and users after installing Windows XP Service Pack 3.
We found that PolicyMaker client-side extensions (CSE) are not registered after installing Service Pack 3. Examine the following location using regedit:
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions
You should see the different client-side extensions for the computer. Here is the list of PolicyMaker CSEs:
{00000040-789B-494F-BF51-216A4110581C} - PolicyMaker License
{08E9566B-1390-4BFB-B19F-EA465BAD922D} - PolicyMaker Environment
{08F5166F-E66B-4F15-80BF-DE94F083472A} - PolicyMaker Local Users and Groups
{0947EA96-E4DE-48C5-99AD-FCC1829FFE86} - PolicyMaker Device Settings
{15D30905-443F-4097-8FA8-0A2E35B475DC} - PolicyMaker Network Options
{1EA5E892-2292-438F-8D05-40E7B0007585} - PolicyMaker Drive Maps
{F0DB2806-FD46-45B7-81BD-AA3744B32765} - PolicyMaker Folders
{F17E8B5B-78F2-49A6-8933-7B767EDA5B41} - PolicyMaker Files
{F27A6DA8-D22B-4179-A042-3D715F9E75B5} - PolicyMaker Data Sources
{F55DA052-16E1-434B-803F-F6A9F6945957} - PolicyMaker INI Files
{F581DAE7-8064-444A-AEB3-1875662A61CE} - PolicyMaker Services
{F5BFF32F-D563-460D-8764-890933FB03C0} - PolicyMaker Folder Options
{F648C781-42C9-4ED4-BB24-AEB8853701D0} - PolicyMaker Scheduled Tasks
{F6E72D5A-6ED3-43D9-9710-4440455F6934} - PolicyMaker Registry
{F9C77450-3A41-477E-9310-9ACD617BD9E3} - PolicyMaker Applications
{FD023FFE-C165-40D5-A201-439FC65AC8A5} - PolicyMaker Printers
{FD2D917B-6519-4BF7-8403-456C0C64312F} - PolicyMaker Shortcuts
{FD44098A-CA65-4054-8A70-EBAFAB263C70} - PolicyMaker Mail Profiles
{FEF373ED-6CBE-4294-83EC-008D502B394A} - PolicyMaker Internet Settings
{FF87F78A-E3A2-4AAE-B049-7E6BB1670D7B} - PolicyMaker Start Menu Settings
{FFAA00BB-0D9B-401B-B71B-EF5ED1D88E6D} - PolicyMaker Regional Options
{FFC64763-70D2-45BC-8DEE-7ACAF1BA7F89} - PolicyMaker Power Options
NOTE: If you have purchased other products from DesktopStandard you may have more. Microsoft did not acquire all the products DesktopStandard offered.
If you are missing these client-side extensions, you can register the DLL’s again by typing the following commands for the product listed:
PolicyMaker Standard Edition:
regsvr32 %systemroot%\system32\polprocl.dll
regsvr32 %systemroot%\system32\polcmncl.dll
DesktopStandard Software Update: (FYI) This product is not supported
regsvr32 %systemroot%\system32\polsucl.dll
DesktopStandard Application Security: (FYI) This product is owned by BeyondTrust
regsvr32 %systemroot%\system32\polseccl.dll
Once this is done, reboot the computer. PolicyMaker settings should start applying again. You can deploy the RegSvr32 commands as a computer startup script, or run the scripts as a post SP3 installation script. For example:
|
@echo off
REM Sample DesktopStandard CSE Registration Script
REM This script is provided "AS IS"
REM with no warranties and confers no rights.
REM For more information please visit
REM http://www.microsoft.com/info/cpyright.mspx to find terms of use.
regsvr32.exe /s %systemroot%\system32\polprocl.dll
regsvr32.exe /s %systemroot%\system32\polcmncl.dll |
Please remember that Policymaker is in extended support and there are no further updates being released. Policymaker has been superseded by the free Group Policy Preferences CSE’s and is included with Windows Server 2008 and RSAT for Windows Vista SP1. GPP can be used on Windows XP and Windows Server 2003 as well.
- Rob Greene
Ned here. I wanted to make sure all of our loyal readers know about an important post at our sister site Enterprise Networking:
NetBIOS browsing across subnets may fail after upgrading to Windows Server 2008
While not a pure DS issue, it could definitely cause DS-related technologies to act oddly or fail. Be sure to give it a quick read.
- Ned Pyle
Sometimes you need to enable additional logging when you are troubleshooting a particular component in Windows. Group Policy Preferences includes the ability to create verbose debug logging for each included client-side extensions. You activate Preference debug logging through Group Policy. Preference debug logging policy settings are located under the Computer Configuration\Policies\Administrative Templates\System\Group Policy node when editing a Group Policy object.
Figure 1 Group Policy Preferences debug logging
You can individually enable each preference client-side extension. Logging and tracing entries provide you with a several configuration options including what type of data to write to the event logs (Informational, Errors, Warnings, or all), enable trace logging and the location of the trace log file, and the size of the file.
Figure 2 Preference Logging and Tracing policy settings
You can configure the location of the trace files; however, keep in mind that file system permissions changed on Server 2008 and Windows Vista. Make sure permissions do not interfere with creating the log file. You'll notice the default location for all three log files is
%COMMONAPPDATA%\GroupPolicy\Preference\Trace. The variable
%COMMONAPPDATA% is not recognized by Windows, however; it is meaningful to Preference client-side extensions. Preference client-side extensions recognize this variable and expand it according to operating system on which the client-side extension is installed. For Windows Server 2003 and Windows XP, %COMMONAPPDATA% expands to
%SYSTEMDRIVE%\Documents and Settings\All Users\Application Data. The equivalent path for Windows Server 2008 and Windows Vista is %SYSTEMDRIVE%\ProgramData (this folder is hidden by default, but you can manually type the path in Windows Explorer).
Logging and tracing missing from RSAT
You've installed Windows Vista Service Pack 1; you've downloaded and installed RSAT. You try to enable Logging and tracing, but it's not there. Well, there is a reason for this.
Figure 3 Logging and tracing missing from RSAT
Administrative Templates show in the user interface because of two files: an .ADMX and an .ADML. Logging and tracing does not appear because the GroupPolicyPreferences.admx and .adml files are not included with RSAT. You need to copy these to your local or central store.
You have two options as to how to get a copy of the Group Policy Preferences ADMX files. You can download the entire Windows Server 2008 ADMX file set, or you can download just the Group Policy Preferences ADMX file set. You can download the installer for either of these file sets from http://www.microsoft.com/downloads/details.aspx?FamilyID=927fc7e3-853c-410a-acb5-9062c76142fa&DisplayLang=en. These MSI applications install their contents to the default location of %PROGRAMFILES%\Microsoft Group Policy.
The Group Policy Preferences ADMX installation creates an additional folder named Preferences, which contains a single ADMX file with multiple locale folders. You want to copy the GroupPolicyPreferences.admx file into your policydefinition folder. If you are using a central store, then you must copy the file to the policydefinition folder on SYSVOL, otherwise; copy the file to your local store. You'll then want to copy the .ADML file to the corresponding locale folder located in your policydefinition folder. See the Managing Group Policy ADMX Files Step-by-step guide for more information on managing ADMX Files and creating a central store. After you've copied both the .ADMX and .ADML file into the proper store, then close all instances of GPMC and its editor. Restart GPMC and edit the GPO in which you want to add Logging and tracing policy settings. Expand the nodes under Computer Configuration and you should now see Logging and Tracing options.
- Mike Stephens
Ned here again. When setting up Distributed File System Replication (DFSR) on Windows Server 2003 R2 and Windows Server 2008, it’s fairly common to hear the following from a customer:
- “I setup DFSR a few hours ago, but it does not seem to be configured on all the servers”
- “I ran the DFSR Diagnostic health report and after hours it still says:
‘This member is waiting for initial replication for replicated folder FOO and is not currently participating in replication. This delay can occur because the member is waiting for the DFS Replication service to retrieve replication settings from Active Directory. After the member detects that it is part of replication group, the member will begin initial replication.’
What’s up here?
How DFSR works
First, a little background. DFSR depends almost completely on Active Directory (AD) and a Domain Controller (DC) to get settings, topology, and all the other goo that configures replication. It pulls them from two places:
Within a global container for the domain, like:
CN=DFSR-GlobalSettings,CN=System,DC=DomainNC
And within each DFSR server’s container, like:
CN=DFSR-LocalSettings,CN=ServerName,OU=SomeOU,DC=DomainNC
This means that for DFSR configuration to take effect, your DC’s must have replicated in the data. Furthermore, DFSR has what we call “DC affinity”. Once it finds a DC, the DFSR service will stick with that DC until the DFSR service is itself restarted. Yes, even if that DC is down or if it no longer exists. The DFSR service will poll its DC every 15 minutes and pick up these changes – if the data is not on that DC yet through replication, the changes will not take effect.
Finding the DC
So now we know the importance of AD to DFSR. When we get the ‘waiting to retrieve’ warning, what can we do to figure out what’s going on? Let’s go through this step by step.
There are a few ways we can determine which DC is being polled.
If we open the Event Viewer snap-in on the server, navigate to the DFSR event log, and then search for the most recent 1206 event, we will see which DC the server is talking to:
The downside to this is the event log may have already wrapped when you look here. If you restart the DFSR service the new event will be added, but there’s the risk that it might start talking to another DC which isn’t having a problem. So your problem is (kind of) fixed, but you still don’t have a root cause.
A more reliable way to determine the DC is by using the WMIC command. Open a CMD prompt as an administrator on the DFSR server and run:
WMIC /namespace:\\root\microsoftdfs path DfsrReplicationGroupConfig get LastChangeSource
This will return the DC you are talking to:
- Examine the DFSR debug logs
Finally, you can examine the DFSR debug logs. Go to %systemroot%\debug and open the DFSR<somenumber>.log file. Look for:
20080521 10:57:47.110 2972 CFAD 7256 Config::AdConfig::Connect Binding to dcAddr:\\10.10.0.10 dcDnsName:\\2003DC10.contoso.com
20080521 10:57:47.110 2972 CFAD 6586 Config::AdConfig::BindToAd Trying to connect. hostName:2003DC10.contoso.com
20080521 10:57:47.130 2972 CFAD 6605 Config::AdConfig::BindToAd Bound. hostName:2003DC10.contoso.com
20080521 10:57:47.130 2972 CFAD 6641 Config::AdConfig::BindToDc Try to bind. hostName:\\2003DC10.contoso.com domainName:<null>
20080521 10:57:47.150 2972 CFAD 6651 Config::AdConfig::BindToDc Bound. hostName:\\2003DC10.contoso.com domainName:<null>
There’s our domain controller. If it’s not in the latest log, you will need to unzip the DFSR debug logs using a tool that understands the GZ format (such as 7-Zip, Winzip, WinRar, etc), and then you can find the entry. As you can tell, using the debug logs is probably the least friendly way to find – but you’ll see later that it’s critical for troubleshooting.
Figuring out why DFSR doesn’t have the info from AD
When we talk to customers in this scenario, DFSR is always blameless – it’s really just exposing a deeper issue in Active Directory. Since we now know the DC in question, let’s run through the five most common reasons why we might be getting this warning:
1. AD replication latency
Active Directory replication is based on the theory of ‘multi-master loose consistency with convergence’. Intra-site replication on Win2003 DC’s will only take fifteen seconds, but by default inter-site replication is 180 minutes (three hours).
So if I have a chain of sites connected like below and my original DFSR configuration was set on a DC in Site B, those three DC’s would have the change available for their DFSR customers within 30 seconds or so. But the DC in Site F might not see it for nine hours.
You have a few options here:
A. Wait patiently and enjoy some light reading.
B. Force replication using REPADMIN (with /replicate /force) or REPLMON (with synchronize directory partition).
C. Change your replication schedule and topology.
So actually this isn’t really always an ‘issue’ per se – just a fact of your environmental configuration.
2. AD replication blocked due to network misconfigurations
It’s possible that your DC is not actually replicating at all. Historically, the most likely reason for this is network misconfigurations. These come from DNS resolution, firewall blocks, etc. To step through the most common areas, check out:
A. Fixing Replication DNS Lookup Problems (Event IDs 1925, 2087, 2088)
B. Fixing Replication Connectivity Problems (Event ID 1925)
C. Troubleshooting RPC Endpoint Mapper errors using the Windows Server 2003 Support Tools
Whatever you suspect, it’s always advisable to start with a REPADMIN.EXE /SHOWREPS on the DC just to get a line on what replication health looks like.
3. AD replication blocked due to topology misconfigurations
AD replication might be in a state where if just knew where its partners were, it could replicate fine. It’s common to find a variety of site topology missteps in environments, so make sure you run down:
Fixing Replication Topology Problems
Your event logs and DSSITE.MSC will tell the tale…
4. AD replication blocked due to lingering objects
Now we have moved past trivial configuration issues into a much more insidious ground. Lingering objects are typically objects that exist in the read-only GC partition of a domain controller but no longer exist in the read-write source domain partition. This can happen when an administrator brings a DC back online after it has been shut off for months; source objects that were deleted and tombstoned are longer available and the old DC can’t be told about the deletions anymore, so he still has ‘reanimated’ versions.
If ‘strict replication consistency’ is in place, that server is not allowed to replicate anymore until it’s fixed (this is a good thing – and if you don’t think so, I will be happy to tell you stories about lingering object cleanup on a forest with 20 domains and 3000 DC’s, all infected with LO’s). So you will want to follow:
A. Outdated Active Directory objects generate event ID 1988 in Windows Server 2003
B. Lingering objects may remain after you bring an out-of-date global catalog server back online on Windows 2000
5. AD replication blocked due to tombstone lifetime
Honestly, if you get this one, you should call us. Event ID 2042 (“It has been too long since this machine replicated”) is tricky to fix without having a frank discussion about the ramifications for your environment. While we do have some techniques, the cure is usually worse than the disease. In most circumstances, the best answer is to forcibly demote the DC because you (of course!) have several other DC’s that can handle the load in the meantime.
Summary
So you came here looking to fix DFSR and left having to fix Active Directory. That’s the funny thing about troubleshooting distributed systems; often the component throwing the errors isn’t actually at fault. In order for DFSR to function smoothly, it needs solid information from its domain controller – keeping that in mind will help you through all your days.
One last thing - I can already hear people yelling ‘USN Rollback!’, ‘Target principal name incorrect!’ and other more esoteric scenarios that might cause AD replication failures. We’re just trying to cover the 99% here, you AD veterans. :-)
- Ned Pyle
Hi everyone, David here. I just wanted to spread the word that ADMT 3.1 is now available for download. Like all previous versions of ADMT, it’s free to install and use.
The big change in this version of the Active Directory Migration Tool is support for migration using Windows Server 2008 domain controllers.
Also included with this are new versions of the Password Export Service (for 32-bit and 64-bit DCs), and an updated migration guide, which we highly recommend for anyone planning to do a migration.
As always, if you’re planning on doing a migration project, we recommend testing carefully before doing anything with production computers and users.
- David Beach
Mike here again. For some time now, we’ve had inquiries about where the Group Policy Management Console (GPMC) is located in Windows Server 2008 or Windows Vista SP1. It’s well documented that Server 2008 includes GPMC but, it does not appear in the administrative tools.
The Group Policy Management Console is included in Windows Server 2008; however, you must install it before you can use it. The domain controller promotion process installs GPMC on the server, in addition to adding the domain controller to the domain. Additionally, you can install GPMC on a member server as long as it’s a member of the domain. Let’s look at two ways to install GPMC on Windows Server 2008 (other than through DCPROMO).
Installing GPMC using Server Manager (Windows Server 2008)
The Group Policy Management Console is a Feature in Windows Server 2008. You install Features using Server Manager. Once installed, you can access the feature using Server Manager or you can the specific management console (like gpmc.msc).
- Open Server Manger by click Start and then point to Administrative Tools. Click Server Manager
- Click Features in the console tree. In the Features pane, click Add Features
- Select Group Policy Management from the list of available features in the Add Feature Wizard. Click Install.
- Start using GPMC or close Server Manager.
There’s another way to install GPMC using Server Manager, which usually installs quicker that using the Server Manager user interface. Server Manager includes a command line utility for installing Features and Roles named ServerManagercmd.exe.
Installing GPMC from the Command Line
- Open an elevated command prompt.
- In the command prompt, type ServerManagercmd –install gpmc
- Start GPMC from the command prompt by typing start gpmc.msc
- Close the command prompt.
Installing GPMC on Windows Vista Service Pack 1
Installing GPMC on Windows Vista Service Pack 1 can be a little confusing. First, you must download the Remote Server Administration Tools for Windows Vista Service Pack 1 before you can install GPMC. You may remember that GPMC was included in Windows Vista RTM; however Service Pack 1 removes it. After installing RSAT, you then want to install GPMC. Installing RSAT simply includes the Remote Server Administration tools on the Windows Vista SP1 computer but does not deploy for use—you’ll want to choose which RSAT tools you want used on the computer.
- Download and install the Remote Server Administration Tools (http://go.microsoft.com/fwlink.?LinkID=95703).
- After the installation is complete, then click Start, click Control Panel, and then click Programs.
- Click Turn Windows Features on or off from Programs and Features.
- Click Remote Server Administration Tools and then click Feature Administration Tools from the Windows Features dialog box.
- Click Group Policy Management Tools and click OK to complete the installation.
You’ll now see Group Policy Management included under the list of Administrative Tools (On Vista, you may need to actually show the Administrative Tools on the start menu – this can be done through Control Panel –> Taskbar and Start Menu –> Start Menu –> Customize –> System Administrative Tools). You can also start GPMC from the command line or run/search menu by typing gpmc.msc.
- Mike Stephens
