PowerShell for Fun and Profit
Posted by Tyler | Filed under Work
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:
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.
Tags: content deployment, powershell, sharepoint
Office 2010: The Movie
Posted by Tyler | Filed under Links, Work
A bit cheesy, but glad to see some news about the next version of Office finally coming out. I wish there were some screenshots or videos in the little movie clip, but it’s early – I’m sure we’ll be releasing that sort of stuff in the future. It’ll be a busy next few months for those of us on the product group, but it’s exciting to finally start telling people about all the cool stuff we’ve built.
Tags: office, sharepoint
SharePoint Permissions “Cheat Sheet”
Posted by Tyler | Filed under Work
Back when we were building SharePoint 2007, a member of our Program Management team left Microsoft, and I inherited the permissions-related features for the then Content Management Server team, which was responsible for all of the web publishing features in SharePoint. Essentially, this meant that I has to figure out what the correct set of permission levels were for our features, and what lists/libraries should have unique (non-inherited) permissions.
Now, if you’ve used SharePoint for any length of time, you’ve no doubt been frustrated with permissions management. It’s definitely a sore point. Unfortunately, I don’t have any magic bullets or golden hammers. When I started trying to figure everything out so that I could make educated decisions for our designs, I realized that I needed to write stuff down. People always asked questions like, “What rights do Designers have by default?” Sure, you can find out by going to the site itself and checking, but the UI isn’t the easiest to navigate, and oftentimes what you really want to do is compare multiple permissions levels. “What rights do Designers have that Contributors don’t?”, for example. To help keep it all straight in my mind (and so I could point people to the info rather than answer 100 emails a day with the same question!), the SharePoint Permissions “Cheat Sheet” was born.
It’s nothing fancy, and it’s certainly not anything that no one else could have created. But still, it has proven useful over the past few years. I still keep a copy of it pinned to my office wall. It’s pretty self-explanatory. The first sheet has a table of the default publishing permission levels and what fine-grain permissions each of them has. The second sheet is just the descriptions of each of the fine-grain permissions so I didn’t have to go hunting through the UI to find them whenever I was wondering what the differences were. Finally, the third sheet is a list of “securable objects” (which what I decided to call a list/library that had broken away permissions inheritance and was independently secured) and what default groups had what rights to those locations by default. This was particularly important since in general, you want to avoid breaking permissions inheritance if you can, and we wanted to be very deliberate about where we did, and also track them to ensure they made sense over time.
So how exactly do you use this? Well, it can be a handy reference as-is, but chances are that you have your own permissions level or have modified the existing ones to suit your needs, so you can modify this sheet to reflect your own custom permissions and keep track of everything. It really is helpful to have a centralized reference of all of the various permissions levels. If you go through and put in your own levels, you might realize that there’s a lot of needless duplication in the custom permission level you might have created. When it comes to SharePoint permissions, less is better, so this can be a helpful auditing tool as well as a reference.
A couple of disclaimers… This was created based on the RTM version. As far as I know, nothing has been changed in SP1 or SP2 that would impact it, but I haven’t been checking to keep it up to date. If you do notice errors you can let me know and I’ll try to correct it. Also, this obviously won’t take into account any customizations that you may do that would alter the default permission levels.
If you use this for any of the purposes listed or for additional things, leave a comment! I’d love to hear how it’s working for you and if it’s been helpful. Download it below:
SharePoint Permissions “Cheat Sheet” (XLSX)
Tags: sharepoint
Accessibility Insanity
Posted by Tyler | Filed under Links, Rants, Work
Part of my responsibilities for SharePoint these days involves markup cleanliness and accessibility, so over the last couple of years I have educated myself on the ins and outs of these issues, and have managed to learn a lot about browser behavior, the history of markup, etc. I am far from an expert, but I know a heck of a lot more than I did when I started.
One school of thought I come across quite frequently is that web content whose markup is not well-formed or is missing required attributes or something just fail to render completely, in order to ensure that all content on the web is gorgeous, standards-compliant markup. This ridiculously draconian viewpoint loses sight of the fact that the ultimate goal of delivering content over the web is just that – delivering content. It seems bad form for a browser to just “give up” when markup is badly formed, because the end-goal of the person building the page – and the person consuming it – is to deliver content. Much of this debate has been chronicled by the IE team; they have a tough job – bring the standards compliance of IE into this century without breaking their customers/users pages. Hence compatibility mode, legacy rendering, etc. etc.
In the past, I’ve always heard this argument from the standards-compliance standpoint. For example, if a page claims to be XHTML but isn’t fully compliant, it should fail to render in a browser. No “best-effort” rendering, just fail. This of course ignores the fact that even the W3C can’t create a parser that can completely validate a page against the spec, but that’s a rant for another time… Assuming the browser can detect that a page is non-compliant, it should just stop.
Anyway, this is a long and winding intro to a post Mark Pilgrim wrote talking about this viewpoint as it applies to accessibility. I had never heard these arguments before, but apparently they’re out there. A choice quote from Mark’s rebuttal (emphasis mine):
I think it would be wise for people who truly care about accessibility to take a closer look at the so-called “experts” who are participating on their behalf, and to understand exactly what these people are proposing. It’s true that some of their proposals have not been adopted, but it’s not because some cartoonishly monocled villain enjoys being mean to them. It’s because the proposals are insane.
Agreed.
Tags: accessibility, sharepoint
SharePoint Updates
Posted by Tyler | Filed under Work
We’ve changed the way we’re managing and releasing updates here in the SharePoint team. This is all very good news. It makes things more manageable internally for us, which translates into quicker, more effective turnaround on issues, but it also means that updates and patches will be much more predictable, so you can plan around those dates more effectively. There is still recourse for you if you have an absolutely critical issue that needs to be resolved ASAP.
More details on this SharePoint blog post and KB article 953878.
Tags: sharepoint
But Why? #0: But why, “But Why?”
Posted by Tyler | Filed under Work
I love hearing stories. When I was growing up I used to love when people would visit and my Dad would tell some of his stories. Even though I had heard most of them a thousand times, it was awesome to sit back and watch other people experience them for the first time. I also read a lot of stories growing up, and I developed a special love for short stories in particular (I especially like O. Henry).
While I was in college, I discovered a site that I have since lost many hours of my life to – folklore.org. It’s a site put together by Andy Hertzfeld (not to be confused with Don Hertzfeldt of Rejected fame), and contains "anecdotes about the development of Apple’s original Macintosh computer, and the people who created it." It is incredible – it combines my love of stories with a topic I find interesting – the early days of personal computing. Best of all, the stories there are written by the people who experienced it, and often contain a healthy dose of humor and humanity. But behind that, there’s some cool technical details about the challenges the engineers faced, and why some of the decisions got made the way they did. I find that part of it utterly spellbinding.
I’ve been on the lookout for other sites like this for other tech companies, like Atari or even Microsoft. The closest I’ve found for Atari is DadHacker.com, written by a guy who worked for Atari back in the day. His blog is interesting in a variety of ways, but I particularly like his Atari posts. In fact, his post titled Donkey Kong and Me was what got him into my RSS reader permanently. It’s good – you should read it.
I actually work with a developer who was also on the team that developed Clippy, and I’ve heard some interesting stories for him about what that was like. Maybe I’ll try to convince him to write up some of his experiences… :-) I am sure there are some more great stories out there… If you know of some sites, please do point me to them.
Because I find this stuff so interesting, I thought it would be good to start chronicling some of the stuff I know about because I’ve been working on SharePoint. Thus, I plan to write a series titled "But Why?" about various SharePoint features that I either worked on or have been exposed to, and why they behave the way they do. These posts will be one part SharePoint history, one part storytelling, and if I do it right, will pull back the curtain a bit so you can see just why things wound up the way they did.
But first, some disclaimers: These posts are my own thoughts and opinions, and do not reflect those of Microsoft or of anyone else who works/worked on SharePoint. Also, my memory may be fuzzy and blatantly incorrect about some things, so everything should be viewed through that lens. Finally, you shouldn’t expect these posts to be as interesting as anything you read on folklore.org. :-)
Tags: But Why? Series, sharepoint
This is the online journal of 
Hello, visitor from the Internet. You may have arrived here expecting to see a site built on top of SharePoint, and are no doubt confused by the fact that tylerbutler.com is running on WordPress. 
You can subscribe to this site in a variety of different ways. The best and simplest way is via RSS. There are three main RSS feeds: