Overview

Google Chrome is fast becoming popular in the enterprise and Google has provided some tools to make deployment and management easier for Windows admins:

• Google Chrome for Business site: http://www.google.com/apps/intl/en/business/chromebrowser.html
• Google Chrome MSI (for deployment via GPO): http://www.google.com/chrome/intl/en/business/download.html
• Google Chrome Group Policy template files: http://dl.google.com/dl/edgedl/chrome/policy/policy_templates.zip

Issue

By default, Google Chrome keeps user settings in the following locations:

Windows XP/2003:

C:\Documents and Settings\<username>\Local Settings\Application Data\Google\Chrome\User Data\Default

Windows Vista/2008 & 7/2008 R2:

C:\Users\<username>\AppData\Local\Google\Chrome\User Data\Default

Unfortunately, due to the fact that Google Chrome keeps user settings in the local application data section of the user profile, it cannot be used with roaming profiles out of the box. For some enterprises, this may be a major road block in deploying Chrome!

Google’s Group Policy templates allow for setting the UserDataDir to another location however unfortunately, if an environmental variable (such as %APPDATA%) is used within the UserDataDir path (ie %APPDATA%\Google\Chrome\User Data), Chrome crashes on startup. It appears that Chrome does not support the use of environmental variables for passing paths via GPO.

Solution

Google seem to have created their own variables rather than using the standard Windows environmental variables.

The current list of Chrome variables on Windows includes:

• %APPDATA% = ${roaming_app_data}
• %LOCALAPPDATA% = ${local_app_data}
• %USERNAME% =  ${user_name}
• %COMPUTERNAME% = ${machine_name}
• %USERPROFILE% = ${profile}
• %PROGRAMFILES% =  ${program_files}
• %WINDIR% =  ${windows}

Other variables:

• ${documents} – The “Documents” folder for the current user. (“C:\Users\Administrator\Documents”)
• ${global_app_data} – The system-wide Application Data folder. (“C:\AppData”)

So for example, to store Chrome’s user data in the roaming application data section of users profiles, I set the UserDataDir policy path to:

${roaming_app_data}\Google\Chrome\User Data

Backup Exec 2010 R3 was failing to perform a single item (GRT) restore to an Exchange 2007 server from either disk or tape (Client is using B2D2T). Both the Backup Exec Media server and Exchange 2007 server were running Windows Server 2008 R2.

The error being displayed was:

Error : e000848c – Unable to attach to a resource. Make sure that all selected resources exist and are online, and then try again. If the server or resource no longer exists, remove it from the selection list. Edit the selection list properties, click the View Selection D

Solution

I checked all the usual suspects and all account permissions, services (Exchange System Attendant) etc were set and running OK.

In the end, I had to modify the hosts file on the Exchange 2007 server with the following:

127.0.0.1                   hostname of the Exchange server
127.0.0.1                   FQDN of the Exchange server
actual IPv4 address    hostname of the Exchange server
actual IPv4 address    FQDN of the Exchange server

Once done, I restarted the Backup Exec Remote Agent for Windows Systems service on the Exchange server.

Official Symantec article: http://www.symantec.com/docs/TECH75728

Often I deploy wireless networks with 802.1X PEAP authentication into Windows Active Directory environments which do not have an existing Enterprise Root Certificate Authority (CA). In environments where there are no further requirements for an Enterprise Root CA, I prefer the simplicity of using self-signed certificates on Windows 2008/2008 R2 based RADIUS servers running Network Policy Server (NPS). These servers are generally Active Directory domain controllers.

Note: Enterprise Root CA services need to be designed and implemented properly rather than simply installed on a whim to generate a certificate!

Issue

So the problem is that it is not possible to generate a self-signed certificate on Windows Server 2008/2008 R2 without installing IIS 7.0 (do you really want IIS on your DCs?) or OpenSSL.

Solution

Back in IIS6 we had a tool called SelfSSL to generate and assign self-signed certificates. SelfSSL is bunded with Microsoft’s IIS 6.0 Resource Kit Tools

SelfSSL is technically not compatible with IIS 7.0 however I have discovered that we can still use it to generate a self-signed certificate on newer servers!

Download and install SelfSSL (do not bother selecting any other components of the IIS 6.0 Resource Kit Tools)

Launch SelfSSL by going to Start >Programs > IIS Resources > SelfSSL > SelfSSL

selfssl.exe /N:CN=fqdn.of.radius.server /K:1024 /V:1825

The above command will generate a new certificate with a key length of 1024 and a validity period of 5 years (1825 days).

When prompted to overwrite the settings for site 1, answer with yes. An error opening the metabase will appear but can be ignored due to IIS 6.0 not being installed on the server.

You will now be able to find the certificate in the local computer certificate store ready for use in your NPS policies or export to other servers/devices!

Basically, some users on a XenApp 5/Windows Server 2008 farm couldn’t print from Office 2007 programs and received an error “Windows cannot print due to a problem with the current printer setup”

The error is caused due to a bug in Windows Server 2008 which does not allow more than a 100 print queues (often Citrix servers will exceed this with mapped client printers etc).

Discussion: http://forums.citrix.com/thread.jspa?threadID=256687&start=30&tstart=0

Hotfix: http://support.microsoft.com/kb/2532459

The  key to fixing this issue is to delete the SusClientId, PingId and and AccountDomainSid from the Registry, allowing the Windows Update Agent to automatically generate a new one.

Once this is done, re-register the computer with the WSUS server using wuauclt /resetauthorization /detectnow

I’ve found a good article explaining the process and providing some example scripts here: http://msmvps.com/blogs/athif/archive/2005/09/04/65174.aspx

Also check the WSUS Support Team Blog: http://blogs.technet.com/b/sus/archive/2009/05/05/resolving-the-duplicate-susclientid-issue-or-why-don-t-all-my-clients-show-up-in-the-wsus-console.aspx

I recently performed an Active Directory domain rename for a client with a Windows Server 2003 functional level domain/forest and Exchange 2003 messaging environment. The client had a single label DNS domain name and needed to move to a proper 2 part DNS domain name for software compatibility reasons. Unfortunately, despite significant planning being put into the project, we ran across an issue with the XDR-Fixup tool during implementation of the domain rename which stopped us in our tracks.

For reference, several excellent articles documenting the domain rename process are available:

• Microsoft TechNet article: http://technet.microsoft.com/en-us/library/cc738208%28WS.10%29.aspx
• Microsoft Step-by-Step Guide: http://download.microsoft.com/download/c/f/c/cfcbff04-97ca-4fca-9e8c-3a9c90a2a2e2/domain-rename-procedure.doc
• MSExchange.org article: http://www.msexchange.org/tutorials/Domain-Rename.html

Issue

The issue we had came when we went to run the XDR-Fixup tool to modify the Exchange server attributes in Active Directory, after completing the domain rename itself, which was successful. The following command was run from the domainrename directory:

XDR-fixup /s:domainlist-save.xml /e:domainlist.xml /trace:tracefile /changes:changescript.ldf /restore:restorescript.ldf

We received the following error:

Operation failed:

No other details were displayed. The changescript.ldf file did not end up being created. The restorescript.ldf file is created but at 0kb with no content.

The tracefile did not show any obvious signs of why the process had errored out.

Solution

The cause of this problem was that some NTDS objects had been removed to the LostAndFoundConfig container in the Configuration partition of Active Directory. For some reason, when orphaned objects are in this container, the XDR-Fixup process is unable to complete successfully.

The solution to this issue was to deny access to any objects in the LostAndFoundConfig container for both the Domain Users and Domain Computers groups.

This can be done as follows:

1. On a domain controller, run adsiedit.msc
2. Add Configuration partition to this tool.
3. Expand it, and locate the CN=LostAndFoundConfig folder to see if there is anything in it, if yes,
   • Select each object in this container
   • View its properties,
   • In security tab, click “Add…”, to add Domain Users and Domain Computers groups into list and Deny them “Full Control”
4. Then, try XDR-Fixup again.

Thanks to Microsoft support for this fix!

I came across this issue today on a Telstra branded HTC HD2 running Windows Mobile 6.5 connected via Telstra NextG. I also had this exact same issue a year ago on a HTC Snap, also connected via Telstra NextG and wish I’d blogged it back then – it would have saved me a lot of time!

Issue

I’m not sure if this is just a bug on some Telstra HTC Windows Mobile devices but when using Microsoft Exchange ActiveSync to synchronise with an Exchange server, the Windows Mobile devices listed above would only synchronise over a WiFi connection. With the WiFi connection disabled or not in use, the devices were unable to synchronise using the Telstra NextG connection and would sit there saying “Synchronizing”. No error was displayed.

It appears that for some reason, these devices do not set the connection to be used by the ActiveSync program, instead leaving the option blank. This means that Exchange ActiveSync never tries to use the 3G data connection if the WiFi is unavailable.

Solution

Step 1

The first part of this solution is to set the device to use the Providers “Internet” connection, even when connecting to a “private network”. This is necessary because these particular devices will always revert to using this connection rather than the default Internet one.

Go to Start > Settings.

Select the Menu button at the bottom right and then choose All Settings.

Select Connections.

Select Connections again.

Select the Advanced tab at the bottom of the screen.

Select the Select Networks button.

Ensure that the option Programs that automatically connect to a private network should connect using: is set to your providers internet connection, such as Telstra Internet

Step 2

Now the Microsoft Exchange ActiveSync server connection needs to be set to use this internet connection.

To setup the connection, go to Start > Tools > ActiveSync

Select the Menu button and either add a new server source or select Configure Server… to edit your existing ActiveSync connection.

Press Next through the settings screens until you get to the screen titled “Edit Server Settings”.

Select the Menu button at the bottom of the screen and select Advanced.

Select a connection to be used by ActiveSync, normally this will be Dedicated. If Internet is selected, from my experence the device may default back to Dedicated anyway.

You should now be able to synchronise your Windows Mobile using Exchange ActiveSync over 3G!

I recently came across the following issue while performing an Exchange 2007 to Exchange 2010 migration for a company that still heavily utilised mail-enabled public folders. The client’s Exchange environment was quite old and had been previously migrated from Exchange 5.5 to 2003 and hadn’t been properly decomissioned with the original move to 2007, but that’s another story!

Issue

The issue I had was that once I moved all receive connectors to the new Exchange 2010 server, emails sent to any of the mail-enabled public folders (which were still being replicated between the 2 servers) was being rejected with the following NDR:

#< #5.2.0 smtp;554 5.2.0 STOREDRV.Deliver.Exception:ObjectNotFoundException; Failed to process message due to a permanent exception with message The Active Directory user wasn’t found. ObjectNotFoundException: The Active Directory user wasn’t found.> #SMTP#

The following error was found in Event Viewer:

Log Name:      Application
Source:        MSExchange Store Driver
Date:          7/09/2010 2:00:02 AM
Event ID:      1020
Task Category: MSExchangeStoreDriver
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      server@domain
Description:
The store driver couldn’t deliver the public folder replication message “Folder Content (PublicFolderDatabase@domain)” because the following error occurred: The Active Directory user wasn’t found.

Solution

Given this Exchange environment was originally running versions prior to Exchange 2007, the legacy Administrative Group and all its empty subcontainers still existed. An explanation from the Microsoft Exchange Team of why this issue occurs can be found here: http://msexchangeteam.com/archive/2010/05/05/454821.aspx

The solution to this issue was to delete the empty Servers container from the legacy Administrative Group.

Using ADSIEdit.msc, connect to a domain controller and navigate to:

CN=Configuration , CN=Services, CN=Microsoft Exchange, CN=[ExchangeOrganisationName], CN=Administrative Groups, CN=[LegacyAdministrativeGroupName], CN=Servers.

Right click the Servers container and select Delete

Click Yes

Mail should immediately starting flowing into your mail-enabled public folders.

UPDATE 25/10/2011

I recently ran into Public Folder replication issues at a client who had moved from Exchange 2003 -> Exchange 2010 that appear to have the same  root cause as the above. Once all Exchange 2003 servers had been decommissioned, Public Folder replication failed to occur between any of the new Exchange 2010 servers (some of which were added after the decommissioning of Exchange 2003). Absolutely NO Public Folder errors were logged in the Event Logs of any of the servers whatsoever, even with all logging set to Expert level.

On a whim, I deleted the Servers container from the legacy Administrative Group. Public Folder replication started working immediately!

Today I ran into an issue at a client where new System DSNs were failing to display in the ODBC Data Source Administrator on a Windows Server 2003 server.

Issue

After creating a new System DSN, the DSN would display in the registry under HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBC.INI however would not be visible in the ODBC Data Source Administrator or available to use by any other ODBC aware application.

Solution

The fix was to delete the default Registry key at:

HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBC.INI\ODBC Data Sources

1. Right-click the key called ‘ (Default) ‘ and select Delete.
2. If unable to delete the key, double-click the key and erase the Data value entered. Once done, the value should read ‘ (value not set) ‘.

MSKB available here: http://support.microsoft.com/kb/2000277