How To…

So if you’re running into an issue where you need to flush DNS on your machine, there are a couple ways to do so… the two most common ways for me at least (long live the command line interface!) are to either pop open a run dialog in elevated permissions mode on a Windows box or open up a term shell on OSX.

I have to say that it boggles my mind on a regular basis when I start talking to end users during a session or when interviewing users in client engagements to find out that they don’t quite understand how the end user and site collection administrator recycle bins work. Most of the time I find that users have the perception that it’s a serial process where once they delete a file, they have thirty days until the file is then moved to a secondary recycle bin where a new timer kicks off – unfortunately this is wrong.

“By default, items in the Recycle Bin are deleted automatically after 30 days. Regardless of whether or not an item is sent to the users’ Recycle Bin or to the Site Collection Recycle Bin, items are deleted automatically after the number of days that the server administrator specified in Central Administration.”

As you can see, it’s plain and simple, 30 days is 30 days, no less no more.

So you’ve deployed an updated solution to your SharePoint 2007 or 2010 farm and you need to recycle the application pool associated with the web application that the solution is deployed to but you don’t want to take down the entire SharePoint farm? No problem, just recycle the single application pool that’s associated with that web application using a quick little command from command shell.

where %SharePointApplicationPool% is the application pool that needs to be recycled. Note that appcmd resides within %systemroot%system32inetsrv

The alternative for this of course is just to go in IIS Manager 6 or 7, select the application pool associated with the web application that requires recycling and recycle the pool manually through the UI.

Back in June 2010, Microsoft released what was known as the Productivity Hub for SharePoint 2010. It was a site collection that Microsoft provided that could be extended out for end users to visit to acquire knowledge on how to use SharePoint. Great resource if you were short on training components and looking for assistance but weren’t able to find their IT Pro (who was probably hiding somewhere no doubt, fearing for their lives). Further for those that are looking to engage and foster adoption of the Information Worker’s in your business, the productivity hub is key to gaining their buy in and helping them to truly dive into the SharePoint platform to make it their tool set.

The best part of the hub in my opinion is the ability to customize it and add additional modules that meet your organization or business unit’s needs to ensure that your implementation is actually serving them from a business perspective rather than just humming away as another file share replacement.

Well, like most technology solutions, there are updates and enhancements. On 17 January 2011, Microsoft released such an update for the Productivity Hub for SharePoint 2010. So, if you’re looking to just download and implement with the content packs – fear not, it’s simply and easy by just heading over to the Microsoft Download Center at:

Are you ever working on a server and you wander away for a few minutes only to come back and find that you’ve been disconnected and your session terminated? Never something fun to work through, especially if you’re installing and configuring a software product.

In most enterprise settings this is something that you’d find in a global policy object enforcing a particular amount of time that you’re able to be Idle prior to being booted from the server. Also there’s another setting regarding the maximum connection timeout – basically how long until your session gets trashed because you decided after you’d been booted for being idle you weren’t going to log back in.

If you’re searching around for these settings, they can be found through your friendly neighborhood group policy object at:

Specifically you’re looking to see what the settings for the following policies are:

Set time limit for disconnected sessions

Set time limit for active but idle Remote Desktop Services sessions

Set time limit for active Remote Desktop Services sessions

Terminate session when time limits are reached

While they may all seem friendly, upon closer examination you’re likely to find that one of these policies is your culprit (more than like the second and third in conjunction with the fourth).

However, oddly enough some folks still use security templates to tighten the policies on their servers. In which case, there’s also a Registry edit required and a reboot. Note you should always backup your registry before you make any changes – not for the squeamish of heart.

You’ll find this information along with other helpful information for allowing and disallowing things like the use of the Clipboard (fDisableClip) in the registry branch of:

Note that it’s still called Windows NT and also Terminal Services – I guess that some things never change 🙂

Specifically you’re looking for the following registry strings to modify:

MaxDisconnectionTime

MaxIdleTime

The decimal values that correspond to these are counted in milliseconds. For instance, if the MaxDisconnectionTime is set to 300000, this corresponds to 5 minutes (60 seconds/minute x 1000 milliseconds/second x 5 minutes). If you don’t want to be disconnected or have a max idle time, just set the value to 0 and you’ll be all set.

Happy Implementing!

And if you’re wondering where the title for this blog post came from, check out the Fireside Theater’s “We’re All Bozos On This Bus” radio show. Has something similar where the robot gets unplugged 🙂

So it would seem that when installing the “Google Apps Sync for Microsoft Outlook” plugin there’s a minor issue with the Outlook 2007 client’s Instant Search Capability. After installing the plugin the drop down for Instant Search within the Outlook client is disabled. I suppose this is to be expected since the Google Search engine has a better grasp of the mail stored in the depths of my Google Apps mail account and its 25 GB of space. However, when changing profiles back to my Exchange profile, I find that the Instant Search is still disabled.

Epic Fail.

While I understand Google’s intent is to be able to assist users in replacing their Exchange profile with their Google Apps e-mail profile with the sync plugin, there are those of us that will continue to use an Exchange profile and the Google Apps capability is a nice to have to be able to use the Outlook client interface.

At first, I thought perhaps this was an Outlook client issue that had been affected by SP2 or some other cumulative update that was applied, however after doing a little Googling, it seemed that no one else had reported a similar experience. I also realized that this behaviour only became apparent after installing the Google – Outlook plugin. So I uninstalled the plugin and wondered, “Will Instant Search work once more?” Negative, Instant Search was still disabled.

Looking within the Search Interface, Windows Desktop Search was telling me that Indexing Outlook had been disabled by the System Administrator. Doing a bit of digging around, it became apparent that I hadn’t disabled WDS, and the mail admins hadn’t done so either, so it was back to square one of looking through the registry to see what had been tweaked. Where else to begin but Microsoft’s documentation pertaining to Group Policy settings and Windows Desktop Search which can be found at:

with a registry key named “PreventIndexingOutlook” set to a value of “1”, telling WDS not to search Outlook under any means. Simply changing this value to “0” and restarting the Outlook client and WDS and Instant Search were back up and running properly across all profiles.

Uninstalling and reinstalling the Google Sync plugin quickly reverted the registry key back to “1”, preventing WDS from indexing Outlook. Even upon uninstalling the plugin, the registry key remained. This seems like a bit of configuration management that should be corrected so as to ensure that users are not limited by Google’s plugin should they decide not to use it without hindering their search capabilities.

Bottom line, this is a registry change that is unexpected that is caused by the Google Sync Plugin. Am I happy to see Google integration with the Outlook client, sure, but not at the cost of Search.