I use task manager a LOT in my job.  I also almost always have a ton of programs running,  therefore, do not have much space on my taskbar and get tired of finding “just the right spot” to right click in on to get to Task Manager.  Saving the following as a .REG file and importing it now allows me to right click anywhere on my entire desktop and launch Task Manager from there:

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\Directory\Background\shell\TaskMan]
@="Task Manager"

[HKEY_CLASSES_ROOT\Directory\Background\shell\TaskMan\command]
@="taskmgr.exe"

You could easily replace this with any other program you frequently run as well J.

Have you ever come across an error like this?

Or perhaps one similar to this?

Unfortunately, these types of “unexpected error” messages do not provide any level of detail as to the actual problem, but instead, only inform you, the admin, there was some type of error that prevented the expected page from coming up properly.

When this happens, there are two changes I make in the application’s web.config file, which have always helped uncover the true problem.

To show the call stack:

Change

<SafeMode MaxControls="200" CallStack="false"
DirectFileDependencies="10" TotalFileDependencies="50"
AllowPageLevelTrace="false">

to

<SafeMode MaxControls="200" CallStack="true"
DirectFileDependencies="10" TotalFileDependencies="50"
AllowPageLevelTrace="false">

To turn custom errors off, so the error and the call stack can be shown:

Change

<customErrors mode="On" />

to

<customErrors mode="Off" />

I’ve seen others mentioning the need to change AllowPageLevelTrace="false" to AllowPageLevelTrace="true", however, I have not had to do this with SharePoint thus far.

One you’ve saved your web.config, the appdomain will be torn down and reloaded on the next incoming request (this happens automatically upon any change to the web.config, by design) and you should be ready to find out your true error.

I recently formatted my wife’s notebook in order to install Windows 7 Release Candidate (RC).  I was curious whether her system was 64-bit capable or not, so I whipped up the following script, which answered the question for me (yes, it was, btw).

This is a very basic script, but answered the question easy enough.  Hopefully, it can help you in some way as well:

On Error Resume Next
Const wbemFlagReturnImmediately = &h10
Const wbemFlagForwardOnly = &h20
arrComputers = Array("localhost")

For Each strComputer In arrComputers
   WScript.Echo
   WScript.Echo "=========================================="
   WScript.Echo "Computer: " & strComputer
   WScript.Echo "=========================================="

   Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\CIMV2")
   Set colItems = objWMIService.ExecQuery("SELECT * FROM Win32_Processor", "WQL", _
                                          wbemFlagReturnImmediately + wbemFlagForwardOnly)

   For Each objitem in colitems
WScript.Echo objItem.DeviceID
WScript.Echo "   DataWidth    = " & objItem.DataWidth
WScript.Echo "   AddressWidth = " & objItem.AddressWidth

If objItem.DataWidth > objItem.AddressWidth Then
         WScript.Echo "Your hardware is 64-bit capable, but you are running on a 32-bit operating system."
End If
   Next
Next

Simply save the above as a file and run it via “cscript <filename.vbs>” as normal.

If you download hotfixes on a regular basis, this may be old news for you, but if not, you may find use in the below.  Most, if not all recent hotfix articles contain the means to obtain the hotfix electronically, without having to call into support beforehand.  This can be a great timesaver.

Here’s how to go about doing it, in detail.  I will be using following article as an example:  http://support.microsoft.com/kb/961755.

This happens to be SharePoint’s WSS February Uber Cumulative Update.  Simply click the link at the top left of the article to view and request the hotfix:

By default, the page attempts to detect your platform, and, if successful, may only show the x86 or x64 version of the hotfix by default, so I’ve highlighted a couple of useful things to click below. The first will show you all available hotfixes for all platforms and languages.  This is not very intuitive and really should be shown by default, in my opinion, to save everyone some grief:

From there you can select both and download as normal.

Finally, if you want to see additional information about the hotfixes, click the “Show additional information” link, as I’ve highlighted above:

This reveals the detailed build information, among other useful things.

Note:  You can enable both options at once to view all of the details, which again, I feel should just be shown by default…

THE Ops Manager…  Here’s my thousand words:

Recently, I ran down an issue with very frequent crashes occurring on one of my customers’ MOSS 2007 x64 Index servers.  Every time it would attempt to crawl virtually any VSD file in the farm, we would experience a crash in the daemon (mssdmn.exe) process.  These crashes made for some very long crawl times, so we had to figure out what was happening.

After some investigation and some great luck meeting someone quite helpful from the search team (thank you, Captain), we came to the conclusion our problem was due to an issue with the Visfilt.dll Visio IFilter itself.  Sure enough, we quickly tracked down a hotfix that contained the fix we needed to resolve this.  The details are explained in article 960502 and this problem only occurs on 64-bit architecture.  Once the fix is installed, you can verify you have the updated VisFilt.dll file by looking in the
“%CommonProgramFiles%\Microsoft Shared\Filters” directory.

What makes this interesting, however, is this is considered an Office Client Cumulative Update package, which means you would not get this fix as part of your normal MOSS patching procedure.

So, the moral of the story is, in addition to keeping current on the standard server side Cumulative Updates (CUs) for MOSS, you will want to also keep an eye out for the latest Office Client Cumulative Update packages which contain updated IFilters (such as the one above), and ensure those are installed on your Indexers in your MOSS farms as well.

Happy Patching!

Every time I install a fresh copy of Vista and/or Server 2008, I have to dig this up and “remember” how to bring back my IE icon on the desktop, since there’s no longer a way in the UI to do it, so I thought I’d share this with you (and me next time I need it!) as well.  Hopefully it will save you some time.

Using Regedit, navigate to the following registry key:

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\HideDesktopIcons\NewStartPanel

Locate the value {871C5380-42A0-1069-A2EA-08002B30309D} in the right pane and change it from a 1 to a 0.

Finally, refresh your desktop by selecting it with the mouse and pressing F5 (or secondary click and choose “Refresh”).

Note:  You can also make this change under HKEY_LOCAL_SYSTEM for a system wide change for all users, instead of for one specific user.  Keep in mind, however, if the value exists in both places, the one located under HKEY_CURRENT_USER will be used.

To save you some time, here are the contents of the .REG file:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\HideDesktopIcons\NewStartPanel]
"{871C5380-42A0-1069-A2EA-08002B30309D}"=dword:00000000

Newly released!

http://msdn.microsoft.com/en-us/library/dd203468.aspx

Check it out.  Definitely good reading here!

Just a quick note to let everyone know of some great long-awaited content that was recently published regarding high availability within MOSS.  The link to the article is here.  There is also a nice Visio that accompanies the article which can be found here.  I definitely encourage you to take a read when you get a few minutes.

I know I am... Like me, you might also like two new downloads that have been recently posted.

Bill Baer recently finished his whitepaper concerning strategies around SharePoint related database maintenance.  I encourage you to download it from here and check it out!  Bill's blog is also located at http://blogs.technet.com/wbaer/ if you would like more great information regarding SharePoint!

Have you ever opened the IIS Manager MMC (quick shortcut - Start/Run/inetmgr) only to find it comes up completely blank?  Also, keen eyes will notice it takes a lot longer for the MMC window itself to appear as well, when this problem occurs.  This phenomena appears to only occur if you have MOSS installed.

In any case, if you have seen this problem on one or more servers in your farm, you can work around it by simply restarting the OWSTimer service ("Windows SharePoint Services Timer" service).  This is fairly acceptable to most since it does not require you to reset IIS or reboot the server (i.e. no downtime).

The good news is there is now a hotfix that should resolve this issue!  Give Microsoft Support a call if you're experiencing this issue.

Just a quick note to let you know the new version (as of 2/25/08) is available for download here.  The previous version (v1.2) was updated last August.

Nothing overly fancy, but useful enough to warrant sharing.  This is something you can use to get your SharePoint farms set up to turn every IIS logging option on.  The good news is each web site in a MOSS farm shares the same web site ID, so it should be pretty easy to batch up:

Option Explicit

On Error Resume Next

Dim CmdLineArgs

Dim CurrSite

Dim CurrSiteObj

' Obtain all command line args

Set CmdLineArgs = WScript.Arguments.Named

' verify args

If (Not CmdLineArgs.Exists("SiteID")) Or _

   (Not CmdLineArgs.Exists("Server")) Then

Wscript.Echo "Error: Invalid number of command line arguments specified."

Wscript.Echo

Wscript.Echo "Usage:  ""cscript FullLogging.vbs /Server:<ServerName> /SiteID:<WebsiteID>"""

Wscript.Quit

End If

CurrSiteObj = "IIS://" & CmdLineArgs.Item("Server") & "/w3svc/" & CmdLineArgs.Item("SiteID")

Set CurrSite = GetObject(CurrSiteObj)

If Err.number <> 0 Then

        Wscript.Echo "Error querying IIS provider: " & CurrSiteObj

        Wscript.Echo "Error = " & Err.number & " - " & Err.Description

        WScript.Quit

End If

CurrSite.LogExtFileDate             = True

CurrSite.LogExtFileHost             = True

CurrSite.LogExtFileTime             = True

CurrSite.LogExtFileClientIp         = True

CurrSite.LogExtFileUserName         = True

CurrSite.LogExtFileSiteName         = True

CurrSite.LogExtFileComputerName     = True

CurrSite.LogExtFileServerIp         = True

CurrSite.LogExtFileMethod           = True

CurrSite.LogExtFileUriStem          = True

CurrSite.LogExtFileUriQuery         = True

CurrSite.LogExtFileHttpStatus       = True

CurrSite.LogExtFileWin32Status      = True

CurrSite.LogExtFileBytesSent        = True

CurrSite.LogExtFileBytesRecv        = True

CurrSite.LogExtFileTimeTaken        = True

CurrSite.LogExtFileServerPort       = True

CurrSite.LogExtFileUserAgent        = True

CurrSite.LogExtFileCookie           = True

CurrSite.LogExtFileReferer          = True

CurrSite.LogExtFileProtocolVersion  = True

CurrSite.LogExtFileHttpSubStatus    = True

CurrSite.SetInfo

wscript.echo "Done!"

Set CurrSite = Nothing

Set CmdLineArgs = Nothing

Have fun.

Edit:  If you want to trim the log size down, do not enable the Cookie field, since this can cause the logs to grow rather large over time:

CurrSite.LogExtFileCookie           = False

Thanks, Todd.

http://jamesbl.spaces.live.com/Blog/cns!BC0D2CA343FFE85A!166.entry

From my alter-ego... This worked well in a pinch.