Stefan Goßner has a great post on his blog covering some common problems that people have with Content Deployment in SharePoint. Problem 13 has to do with the default timeout window for Content Deployment jobs. Stefan provides some sample code that you can use to adjust the timeout value, since it’s not exposed through the UI, but I find writing and running sample code on a server a bit of a pain. Instead of writing code, you can actually use PowerShell to do this directly from the PS prompt.

The key to doing this is loading the SharePoint DLLs into your PowerShell environment. You can do this using the System.Reflection.Assembly class. Take a look at this sample script:

#!powershell
param( $newTimeout = 600 )

[System.Reflection.Assembly]::Load("Microsoft.SharePoint.Publishing, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c")

$cdconfig = [Microsoft.SharePoint.Publishing.Administration.ContentDeploymentConfiguration]::GetInstance()

$cdconfig.RemoteTimeout = $newTimeout
$cdconfig.Update()

"Updated RemoteTimeout to $newTimeout seconds."

In line 3, I load up the Microsoft.SharePoint.Publishing DLL, then I grab the ContentDeploymentConfiguration (line 5) using the GetInstance() static method. I update the RemoteTimeout property, then call Update(), and we’re done. No code to write and compile.

This example uses the param keyword, which means you can save it as ChangeRemoteTimeout.ps1, then run it like this:

PS C:\> ChangeRemoteTimeout –newTimeout 1200

This is completely optional, of course, but if you find yourself doing this a lot, it might be worth saving it as a reusable script.

You might also want to make changes to some of the options that are exposed through the UI already. Here’s an example:

PS C:\> [System.Reflection.Assembly]::Load("Microsoft.SharePoint.Publishing, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c")
PS C:\> $cdconfig = [Microsoft.SharePoint.Publishing.Administration.ContentDeploymentConfiguration]::GetInstance()
PS C:\> $cdconfig.AcceptIncomingJobs = $true
PS C:\> $cdconfig.RequiresSecureConnection = $false
PS C:\> $cdconfig.Update()

In this case, I’m configuring the farm to accept incoming deployment jobs and not require secure connections. You can also make additional changes to other properties, such as FileMaxSize and RemotePollingInterval using this method. Stefan covers these properties in his Pimp My Content Deployment Job post.

One other note… Using .NET DLLs in PowerShell is generally supported across the board. It’s not limited to the SharePoint DLLs. There’s some pretty exciting stuff you can do here once you start playing around.

Fascinating piece of technology that I’d never heard of: the watchclock. For fun, read the first part of the article, which describes the scenario and use-case, then try to design a solution before you read further.

Great xkcd today about what gets kids interested in science.

A few years ago I realized that when I would start reading an interesting article on Wikipedia, I would often end up reading 6-8 additional articles that were linked from the original article, then branch out from there, etc. etc. I’d end up in a completely different subject than the one I’d started in, and I learned a lot, plus it was just a ton of fun.

I started calling these Wikipedia Walks. The concept is simple - start at an article you find interesting, then just continue on to any articles linked from the original. Finish when you get bored. To make it more interesting, you should record both the starting article and the ending article, so you can see just how far off the beaten path you’ve gotten.

To start, I’d suggest the article on Game Theory.

IT security consultant Rich Mogull gives some tips for seeing through the BS in security press releases. It’s aimed at the Mac community, but it has some insightful info that applies across the board. In particular, I like his even- handed evaluation of the relative security of both Windows and OS X:

For many years Mac OS X did have an inherent security advantage over Windows, but to those who understand the technologies within the operating systems, those days are long past.

The latest version of Windows (Vista, not that most people use it) is provably more secure in the lab than the latest version of Mac OS X 10.5 Leopard. Leopard lacks proper implementation of the new anti-exploitation technologies included in Vista, and, based on the number of Apple security patches, experiences about as many vulnerabilities.

When I see articles that defend Mac OS X based on the lack of Mac-specific malicious software, and not on current technical capabilities, cybercrime dynamics, or attack methods, I tend to be dubious.