Month: April 2011

Today I visited a customer site where the customer had setup a central store, meaning all group policy defintion files and language files are placed in the SYSVOL share for better management of group policies. One benefit of that central store is that all administrators managing and editing group policies are using the same templates.

The problem in this case was that whenever they started editing a group policy they got tens and tens of warning about various admx files along with for example resource errors. I looked into PolicyDefinitions folder in the SYSVOL share and immediately noticed that there was admx and adml files missing and that there were mismatch between the version of the admx and adml files.

I took a Windows 7 with SP1 client and added/replaced all admx files from there. After that I took the en-us folder and replaced what was in the SYSVOL folder with that one, followed by doing the same for the sv-se, i.e. the Swedish language files. While at it I installed IE9 and put in the inetres.admx and respective adml files for each language to have the capabilities of editing Internet Explorer 9 policies as that is to be included in the Windows 7 image. Voila!

So the bottom line is; keep the central store consistent and make sure that when you create the store that you populate it with admx and adml files from the latest client OS with service pack when managing Windows 7, and that you do make sure that you have the same version of all admx and adml files or else you will get errors due to mismatching files.

When companies deploy Windows 7 most of them are looking at the 64-bit version of Windows 7. This architecture of Windows does not support running 16-bit applications, which unfortunately still is widely in use. If you do an inventory with ACT (Application Compatibility Toolkit) it will inventory all executables as well as CMD files and some other stuff and it will contain information about 16-bit applications lying around and being used by the users in your business.

The trick is that the GUI does not provide a way to view these applications so you have to turn to doing a SQL query using for instance the SQL Management Studio Express tools. Use the SQL Query below to get information on any none 32- or 64-bit executable. The query (thanks to Chris Jackson) will return for instance WOW (Windows on Windows) or DOS applications and that will/might indicate a 16-bit app which you should prioritize to test and handle as necessary.

USE ACTDATABASE
GO

SELECT DISTINCT Applications.appName, Static_App_Properties.fileName, fileModuleType

FROM Static_App_Properties
INNER JOIN Application_Instance_Files
ON Static_App_Properties.identity_hash = Application_Instance_Files.filePropertyID
INNER JOIN Applications
ON Application_Instance_Files.appID = Applications.identity_hash

WHERE fileModuleType<>'32BIT' AND fileModuleType<>'64BIT' AND propertyType='File'

ORDER BY appName
GO

Happy hunting for 16-bit applications! :)

Mapping printers using Group Policy Preferences is a really nice feature and it is supposed to be working much better than using traditional scripting technologies. Let me tell you about an interesting day troubleshooting why printers didn’t want to map using Group Policy Preferences. In the logs it just stated “catastrophic failure” which does not sound good at all nor makes much sense.

Log Name: Application
Source: Group Policy Printers
Event ID: 4098
Description: The user 'X' preference item in the 'Y {3EE4E80F-17CB-4E56-9237-4FC8B9FA090A}' Group Policy object did not apply because it failed with error code '0x8000ffff Catastrophic failure' This error was suppressed.

Logging in as the user on another machine did not produce the same problem and the mapping of printers work fine, as did mapping the printers when logging in using an administrator account.

This got me thinking that I should try mapping a printer manually as the standard user so I did. It got me a “You do not have permission to use the selected printer” which made me turn to the classic tool Process Monitor and to start a trace. It didn’t take long to see that after filtering all logs for a result of “denied” resulted in the following line:

Operation: CreateFile
Result: ACCESS DENIED
Path: \\printserver\print$\w32x86\3\OPLO_UM.dll
Desired access: Generic Read

Note that CreateFile does not necessarily mean to create a file, it can mean “read file” as documented by Microsoft for the CreateFile function. 

So the conclusion was that after investigating with the printer department the printer share “print$” security permissions did not match the user and the user actually did not have read permissions to read the driver which is an absolute requirement for the printer to be mapped (as the print driver is actually installed when the printer is mapped).

Also one setting that affected the behavior was that one have to set “Run in logged-on user’s security context” in the Common tab of the printer mapping Properties. This is an essential part of the solution…

Case closed!