My Insights

If you find yourself supporting/fixing computers for friends and family members, then LogMeIn is an indispensable tool for you. I use LogMeIn Free to remote control the computers that I support and the reason that I love this tool is because it does an excellent job of punching through firewalls AND it requires absolutely no interaction from the person being helped in order for you to establish a remote connection. You need to install a small program that runs on each computer that you support - ideally this can be setup by you the next time you get called for support.

System Tray Icon

What I don’t like about the client side software is that it puts an icon in the System Tray. However, I have found that you can kill this icon using the registry without impacting any functionality. This way LogMeIn is completely transparent to the end user and you have the ability to remote control their computer whenever they are experiencing an issue. In order to remove the icon from the system tray, remove the following entry from the registry-

HKLM\Software\Microsoft\Windows\CurrentVersion\Run
Delete "LogMeIn GUI"

The next time you restart your computer, the system tray GUI will not run but the core LogMeIn processes will run, giving you complete access to their system.

Vista Update (10/10/2007): It seems that the system tray icon may give you some trouble on Vista machines. The simplest workaround right now is to simply rename the executable located here: C:\Program Files\LogMeIn\x86\LogMeInSystray.exe to something else. Change the executable in the x64 folder on 64-bit machines. If you find a better workaround, please post it in the comments.

Authentication

The other part that might be tricky is the fact that you need a local user account on the machine that you are going to support. Now I haven’t completely figured why this happens, but apparently depending upon the mood of the installer, you may be prompted by the installer to create a “Computer Access Code”. What this really means is that the installer has created a user account for you on that local box called “LogMeInRemoteUser” and has hidden this user account from showing up on the XP Welcome Screen or on the User Accounts management tool in the Control Panel.

I wasn’t too comfortable using “LogMeInRemoteUser” on some machines and a personal local account on other machines. Therefore, I chose to create personal accounts on ALL machines that I support and deleted the LogMeInRemoteUser account in an effort to maintain consistency. I will not be covering the steps to create a local user account.

First thing I wanted to do was to hide my personal account from the XP Welcome Screen and from the User Accounts management tool in Control Panel. To do this, add the following DWORD to the registry-

HKLM\Software\Microsoft\Windows NT\CurrentVersion\WinLogon\SpecialAccounts\UserList
Add DWORD for "AccountName" and set value to 0 to hide it from the UI

My Personal Account’s username is “Pranav” so I just create a DWORD for “Pranav” and set it to 0 ni the location mentioned above.

If you were prompted to create a Computer Access Code during installation, then the installer created a local account called LogMeInRemoteUser and you’ll notice that there is a DWORD entry in the same location for that account. Simply delete this DWORD and you’ll now see this account in the User Accounts management tool in Control Panel. You can then go ahead and delete this account if you wish to do so.

Conclusion

I am loving the product so far - especially since it is FREE and EASY. I have also been able to make this experience completely transparent for the people that I support and that is a great plus point for me. Please share your suggestions/experiences in the comments below.

We recently upgraded one of our SharePoint boxes to Service Pack 2 of Windows Server 2003. The upgrade broke our Content Deployment from the upgraded server to any other servers. The error message in Central Admin said something to the tune of “The remote web upload request failed”

Upon further investigation I found out from the IIS logs on the target machine that all the exported .cab files were actually being transferred over successfully and IIS was returning back a status code of 200 for each transfer. However on the last CAB file upload, IIS returned a status code of 400 every time for some reason. After that, everything just died out and the source machine could not confirm that the transfer was complete.

Rob has a more detailed account of why SP2 broke Content Deployment but in short, the fix involved making changes to the registry since service pack 2 has issues with networking and I am being told that there is no way to roll-back from SP2.

SharePoint 2007 has really nice looking alerts that you can configure from the site itself. For example, you can subscribe to a discussion board by clicking “Actions > Alert Me” and you will start receiving alerts if and when there are changes on that discussion board.

However, if you want to make changes to how the alert email looks - perhaps to make the email look more like your corporate emails - you have to modify a file called alerttemplates.xml located in C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\XML. Combined-Knowledge has a great white-paper on how to do so.

However, I just wasted a bit of my time figuring out why my changes were not taking effect. It turns out that after making changes to your alert template, you must use the stsadm -o updatealerttemplates to update the alert template for the site collection you want. Then you MUST re-subscribe yourself to receive the alert by clicking “Actions > Alert Me“

It appears that the site creates a separate alert template for each user. Seems inefficient if it is true - can someone confirm this?

I have an email invite from google for Grand Central. I am already signed up so it doesn’t do much for me. If anybody wants it, email me [firstname]@[firstname][lastname].[com]