TMG 2010 currently don't support Internet Explorer 9.0

Hi Everyone,

Don't install IE 9 on your TMG server. The console will not works after the installation :)


Also see the following links:


Tags: ,

Microsoft UAG 2010 : Powershell Script Error - Failed. Windows cannot open the file named c:\users\\AppData\Local\Temp\......

Hi UAG folks,

During a deployment of UAG 2010 in a test lab I bumped into a small issue with getting UAG to update the GPO policies in Active Directory.

When you click "Apply Now" and execute the Poweshell it will output within the UAG console and you might get an error if you use special characters in either your username or "%TEMP%" user environment variable.

It doesn't seem that the script was build with support for error handling and  expecting special characters within the %TEMP% variable.

The error you might get..

failed. Windows cannot open the file named c:\users\\AppData\Local\Temp\...... Yell


To get around this issue the easy way is to change the %TEMP% variable. You could decide to use a more normal username that doesn't include special characters... Wink

Changing the %TEMP% variable.


See this Microsoft KB article for more information.

Powershell and Special Chars:


Peter Dahl



OpsMgr : The value provided for the report parameter 'EndDate_BaseValue' is not valid for its type. (rsReportParameterTypeMismatch)


A few weeks ago I was asked by a customer why he couldn't drilldown in the "OpsMgr Scheduled Reports" that he received weekly/monthly. He used the rendering format "HTML 4.0" which means that he received a HTML document containing the report, values used within the report and with reference to the report server (Microsoft SQL Reporting service SRS) to drill further down. Drilling down in these "OpsMgr Scheduled Reports" may result in error like this:

- "The value provided for the report parameter 'EndDate_BaseValue' is not valid for its type. (rsReportParameterTypeMismatch)"

The HTML document contains all parameters used to create the report like start time, end time and etc..



The issue is caused by a "Time format" difference between the client and the report server. In Denmark the date and time format is "dd-MM-yyyy" and the United States another format like "m-d-yyyy" is used.

If you see the picture below you will see that the client will pass the client date format as a parameter in the URL. The issue occurs even though the "ParameterLanguage" is also passed?



Change the Regional Settings on the client to match the server.

Please find a guide here:


ParametersLanguage =


Marnix Wolf  mentions a similar issue in this article:




Monitoring DFS-R BackLogs with OpsMgr


Here is a good article that explains how to configure DFS-R monitoring and how to keep track of the DFS-R BackLogs.



DFS-R and the "Too long file names" / "MAX_PATH" limitation

Hi everybody,

Some point in time everyone have experienced the issue with some filenames being to long and can't be deleted/moved.


The other day I got ask by a cusomter whether this limitation also applied to DFS-R replication. I didn't know so I had to research it... :)

Normally this issue applies to all versions of Windows because it is limitation of the Win32 system. The application and services are usually affected by this issue.

I've discovered that the limitation DOESN'T apply to the DFS-R replication :)


Documented here:

After reading through DFS-R reference docs "DFS Replication: Frequently Asked Questions (FAQ)"

Search for "Is there a file character limit or limit to the folder depth"

The limitation is explain in these articles: