When you redirect the Documents folder on a Windows 7-based computer to a network share, the folder name unexpectedly changes back to Documents. But we expect the folder name to be the user name.

Here are reproduce steps:

Server : Windows 2008 R2 STD (US)
Station : Windows Seven (Fr)

1.    We defined a hidden share as the home folder in Active Directory.
Ex :
\\Server\Users$\User1 (home folder for user 1)
\\Server\Users$\User2 (home folder for user 2)
2.    In GPO:
Configure the Folder redirection Setting with this parameter :
Basic - redirect everyone's folder to the same location
Redirect to the users home directory
Move the content of Documents to the new location
Also apply redirection policy to windows 2000 etc...

3.    When log to the server and browse "users" directory, the user directory appear like he was renamed in "My Documents"
Ex :
D:\users\My Documents
D:\users\My Documents
D:\users\My Documents

The folder are not really renamed, it was just the display that was incorrect.

4.    If using a command line to browse the directory, the folder appear with the good name.
D:\users\user1
D:\users\user2
D:\users\user3

This behavior was firstly observed in Windows Vista and still in Windows 7.
It appears to be a change from Windows XP - in XP, redirecting to the folder does not change the display name of that folder.

More information:

http://support.microsoft.com/default.aspx?scid=kb;EN-US;947222

These days, we are monitoring this issue:
when one was developing a utility that monitors log files as they are updated.

On 2003, opening the log file folder in explorer, you can see the timestamp and files size change before your eyes each time the log is updated.

On 2008, "Last Modified" field on log files is not updated unless another
program attempts to open the file or the utility is stopped, even if F5 is pressed to
refresh the view.

Explorer gets is information from NTFS, by using a cmd prompt and "dir" we found that the NTFS metadata for the files is not updated until the handle to a file is closed.

Refreshing the information of a FOLDER is just going to go to the (memory resident) metadata cached by NTFS, but querying the file explicitly will force disk I/O to get the properties - this was a design change introduced in Vista to reduce unnecessary disk I/O to improve performance

There are some exceptions to this rule:
- in some, but not all, cases a simple "dir filename" is enough to refresh the metadata
- "special" folders may be treated differently, such as user profiles where we do not expect a large number of files and want to be able to rely on the file data presented
- kernel filter drivers may change the behaviour as by design they "add, remove or
change functionality of other drivers"

As the workaround is for any process to open and close a handle to the log files, a tool was written to do exactly that, plus get the file information, using the following APIs:
CreateFile
GetFileInformationByHandle
CloseHandle


Reference:
http://social.technet.microsoft.com/Forums/en-US/winservergen/Thread/2B8BACA2-9C1B-4D80-80ED-87A3D6B1336F

Group Policy - Event Log Service | Security | Maximum Log Size (KB) forces a minimum size of 20480 KB.
Explain text lists minimum as 1024 KB as following text:
“If you enable this policy setting, you can configure the maximum log file size to be between 1 megabyte (1024 kilobytes) and 2 terabytes (2147483647 kilobytes) in kilobyte increments.”
Eventvwr.exe lists minimum as 1024 KB
It's easy to reproduce this problem
1.    Open group policy editor
2.    Go to “administrative template” -> “Windows Components” -> “Event log service” -> “Security”
3.    Double click “maximum log size(KB)”
You can not set log size smaller than 20480KB. But explain text said yes.
We hope fix will be published soon.

Auditpol command and secpol UI display inconsistent auditing policy result. If you modify some audit policy through auditpol command, the secpol can't detect this change. (Win2008 R2 SP1 RC still have this issue)

Repro Steps:
1.    in order to describe this issue more exactly, we use one of the audit policy(“logon/logoff”) as an example.
2.    First ,type “auditpol /clear” in your command prompt with administrative privilege to reset all the auditing setting to default value.
3.    Run “auditpol /get /category:*” to make sure the “logon/logoff” policy was not configured, and also run ”secpol.msc” to make sure the “logon/logoff” policy under advanced audit policy configuration was not configured.
4.    Run “auditpol /set /category:”logon/logoff” /success:enable” to modify this policy.
5.    Run “gpupdate /force”
Then we can see the inconsistent result between the auditpol command prompt and the secpol.msc UI.
Run “auditpol /get /category:*”  in command prompt, from the output we can see the “logon/logoff” policy was modified. But from the secpol.msc UI the “logon/logoff” policy was still not configured

it seems the secpol UI can't detect the change made through auditpol command , so it make the inconsistent output between these two tools. Hope the fix will be published soon.

In windows 2008 R2 SP1 RC, during install the WDS role, if you uncheck “Transport server” role service ,and then go ahead follow system’s request to remove dependent role services, the server manager MMC will crashed.(This works fine in windows 2008 R2)
We can easily reproduce this issue:
1.    Open server manger console
2.    Click “Roles”->”Add Roles”, click “Next”, select the “Windows Deployment Services” and double  “Next”.
3.    In the role services page ,uncheck the “Transport Server” role service box
4.    The “Add Roles Wizard” will ask you to remove the dependent role services if you want to remove “transport server” role service
5.    Click “Remove Dependent Role Services”
6.    After that “Server Manager” crashed with following error: MMC has detected an error in a snap-in and will unload it.
7.    Then click “OK” ,following the error message:
FX:{18ea3f92-d6aa-41d9-a205-2023400c8fbb}
Exception has been thrown by the target of an invocation.

It seems the server manager MMC can’t handle the add role services correct. and it's an obviously product bug that comes with the SP1 RC .

Only workaround is to uninstall SP1, install WDS role and then install SP1 back. Hope SP1 will fix this problem.