One way to get around desktop shortcuts missing ...

So, there is this scheduled maintenance task in Windows 7 which runs every Sunday at 1:00am and  removes broken desktop shortcuts if more than 4 are found.  (I am still a bit puzzled about the word "Broken".  In my tests I created some shortcuts which points to some network shares, they are legitimate desktop shortcuts but when the maintenance scheduled task ran, it found them to be broken for whatever reasons and removed them.  I am guessing that it might not have permission to access those files/shares and thefefore classified them as broken???)

The maintenance task actually runs some powershell scripts located at c:\windows\diagnosis\scheduled\maintenance which performs several maintenance tasks.  However, the one which we are interested in is called "TS_BrokenShortcuts.ps1"

This is my idea and I am yet to cofirm this.

The TS_BrokenShortcuts.ps1 is owned by "TrustedInstaller", so even the administrators will not have permission to modify it.  So, we will have to take ownership of the file.

- Bring up an elevated command prompt and issue this command:  What this will do is to change the owner of the file to Administrators.
"Takeown /f C:\Windows\diagnostics\scheduled\Maintenance\TS_BrokenShortcuts.ps1 /A"

- Copy this file to a source location and change the number 4 to let say 50, which the maintenance task will only delete the broken shortcuts if  over 50 are found.  Come on..  50?  You got to be kidding me!!
(Get-ListLength $brokenStartupShortcuts)) -gt 4))

- Now, being the owner doesn't mean you will have permission to write/modify this file.  So, we will have to change the ACL (Access Control List) of this file.  Issue the following command will grant Administrators to have Full Control over the file.
icacls c:\windows\diagnostics\scheduled\Maintenance\TS_BrokenShortcuts.ps1 /grant Administrators:F

- The final step would be to copy the modified  TS_BrokenShortcuts.ps1 file and override the original file. 
xcopy TS_BrokenShortcuts.ps1 c:\windows\diagnostics\scheduled\Maintenance\TS_Brokenshortcuts.ps1 /y

Depending on what you want to do, you might want to consider deleting this file so that this particular task will never execute again. (Again, I am yet to confirm this!)

Now, the challenge is, how do I accomplish all these in SCCM OSD Task Sequence.  My quest continues...

[Updates  Feb 11th 2011]
I implemented the above findings to SCCM OSD Task Sequence with the following and it works like a charm.  The TS_Brokenshortcuts.ps1 is deleted and the Maintenance Task will not remove anymore broken shortcuts from now on.

1.  Run command Line "Takeown /f C:\Windows\diagnostics\scheduled\Maintenance\TS_BrokenShortcuts.ps1 /A"

2.  Run Command Line "icacls c:\windows\diagnostics\scheduled\Maintenance\TS_BrokenShortcuts.ps1 /grant Administrators:F"

3.  Run Command Line "cmd.exe /c del c:\windows\diagnostics\scheduled\Maintenance\TS_BrokenShortcuts.ps1 /q"

(Note that when running OS command, such as "Del, Ren" etc, make sure you do the "cmd.exe /c <command>")

Deskop shotcuts gone missing after Windows 7.

I been hearing a lot of the complains from users about their desktop shortcuts gone missing in Windows 7 especially over the weekend.  Digging around the internet concludes that it is a known behavior of the System Maintenance Troubleshooter which runs every Sunday at 1am.  (The name of the task is called  Scheduled under Diagnosis in Task Scheduler).  If it finds more than 4 broken shortcuts, it will removes all the broken shortcuts.

As detail in http://support.microsoft.com/kb/978980/

The System Maintenance Troubleshooter runs a few maintenance tasks (powershell script) which can be found in C:\Windows\diagnostics\scheduled\Maintenance.

There are a few ways to deal with this:

1.  Keep broken shortcuts to less than 4.  (I think this is going to be a challenge for some users)

2.  Take ownership of the powershell script "TS_brokenshortcuts.ps1" and modify | rename | delete it.

3.  Disable the task in the task scheduler which is not a good idea as it runs other maintenance tasks as well.

It took me a while to work out how to use the schtask.exe command to find the right tasks for this one.
When you use "schtasks.exe /query", you will see the "Scheduled" task name which  System Maintenance Troubleshooter runs.   However, if you do a -- schtasks.exe /change /disable /TN "Scheduled"--, it will return an error because it couldn't find a task name called "Scheduled".

The Syntax is actually -- schtasks /change /disable  /TN "\Microsoft\Windows\Diagnosis\Scheduled" --

Software not getting installed from SCCM. execmgr.log showing spRebootRequest->JobStart failed 0x80004005

I ran into a situation a couple of times where softwares are not getting installed on the systems via SCCM deployment.  Upon checking the execmgr.log file,  I am seeing the job failed start with error messages spRebootRequest->JobStart failed 0x80004005.

As detailed in http://support.microsoft.com/kb/970635, under very rare condition, the job counter is not decremented when the job is finished.  The coordinating system prevents the system from being restarted because it thinks that the job is still running based on the job counter value.

The way to get it going again. 

1.  Check the registry key (HKEY_LOCAL_MACHINE\Software\Microsoft\Sms\Mobile Client\Reboot Management\JobCounter) and make sure that the value is not greater than 0

2. Restart the system manually.

Windows 7 RDP session randomly disconnected. (Part 2)

More researches lead me to this Microsoft KB article.
http://support.microsoft.com/kb/2083411

The above article make sense because users are being disconnected from RDP session randomly which match the interval of group policy refresh.

I have adjust the registry key to set to "0" manually and doing a final test to confirm the resolution.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server
fDenyTSConnections.

This article is also useful.

http://setspn.blogspot.com/2010/12/remote-desktop-session-disconnection.html

Windows 7 RDP session randomly disconnected. (Part 1)

Users are experiencing RDP session disconnected randomly when connected remotely to servers via RDP session.  Checking at the event log.  You will see the following errors:
EventID 56 : Source TermDD
The Terminal Server security layer detected an error in the protocol stream and has disconnected the client. Client IP:  X.X.X.X
EventID 50 : Source TermDD
The RDP protocol component X.224 detected an error in the protocol stream and has disconnected the client
I did some research and found the following:


http://blogs.technet.com/b/askperf/archive/2010/03/25/the-curious-case-of-event-id-56-with-source-termdd.aspx


http://social.technet.microsoft.com/Forums/en-US/winserverTS/thread/ab950c6e-847a-4f51-bc15-b9f54793787c


Suggested cause of actions are:
1.  Disable Autotunning in the TCP to determine any improvement:    Open up an elevated command prompt and issue the following command.

netsh interface tcp set global autotuninglevel=disabled
netsh interface tcp set global autotuninglevel=normal 
(this will reverse the change if you find it has adverse effects.)
netsh interface tcp show global
(to show the TCP settings)


2. Set the MTU to 1300 (Default is 1500)

netsh interface ipv4 show interface
netsh interface ipv4 set subinterface "Local Area Connection" mtu=1300 store=persistent
I carried out with some test and couldn’t come to a conclusion with this. After adjusting the MTU size, I managed to keep the RDP connection for over 2 days now without disconnection.  I will have to keep monitoring this one.

Event 8194, The Client-side extension could not remove computer policy settings for { } because it failed with error code '0x8007000d The data is invalid.' See trace file for more details.

I am seeing this error in the application event log on a few Windows 7 clients.
"Event 8194, The Client-side extension could not remove computer policy settings for { } because it failed with error code '0x8007000d The data is invalid.' See trace file for more details."

Resolution:


- Log on to the machine
- Open Windows Explorer
- Navigate to %ALLUSERSPROFILE%\Application Data\Microsoft\Group Policy\History
- Delete all subdirectories under History.  (Please note %ALLUSERPROFILE% would be c:\programdata)


- Open a command prompt
- In the command prompt, enter gpupdate /force
- Verify that subdirectories will populate under %ALLUSERSPROFILE%\Application Data\Microsoft\Group Policy\History

Note: %ALLUSERSPROFILE%\Application Data\Microsoft\Group Policy\History contains a copy of the preferences contained in GPOs. If the copy process failed somehow, an invalid XML file may be left in one of the subdirectories, thus creating the 0x8007000d Error. By following the method described above, a clean copy of the GPOs is created and the GPO is working again.

Also, The following GUID registry keys under both of the following will need to be deleted too.

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\History
HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\History