Showing posts from 2012

Enforcing Site Policy Selection in SharePoint 2013

One of the new features in SharePoint 2013 is the ability to create and publish  site policies . Essentially, a site policy defines when a site should be closed and when it should be deleted, together with any reminders, workflows, and so on that you want to associate with the process. You create site policies at the site collection level, and you can then publish them through a Managed Metadata Service application to make them available on other site collections. One of the big selling points of site policies is that you can use them in conjunction with self-service site creation. The basic idea is that you allow people to create their own sites, but mitigate the associated risk of site proliferation by forcing them to select an appropriate site closure and deletion policy as part of the site creation process. This is all well-documented elsewhere, so I don't plan to go into it here. Instead, I want to focus on a couple of specific issues that stumped us for a couple of hours.

Problems Viewing Health Reports in SharePoint 2013

I've been faced with an interesting problem over the last few days when working with the SharePoint 2013 RTM build. I'm using SharePoint 2013 RTM on Windows Server 2012 and SQL Server 2012 RTM on Windows Server 2012. I configure usage and health data collection in Central Admin using default settings. I click View health reports . I specify some criteria under Slowest Pages , and click Go . I then get presented with the following error message: Sorry, something went wrong You can only specify the READPAST lock in the READ COMMITTED or REPEATABLE READ isolation levels. This took quite a bit of troubleshooting. When you click Go on the Health Reports page, SharePoint calls a stored procedure named  proc_GetSlowestPages in the WSS_Logging database. After spending some time messing around with SQL Server Profiler, we established beyond doubt that the call to the stored procedure is using the default READ COMMITTED transaction isolation level. The problem lies in a conflict be

Enterprise Deployment Tutorial Series Published

Microsoft's web platform includes various tools and technologies which, together, give you a whole lot of control over your web deployment and ALM scenarios. Visual Studio tooling, MSBuild, the Web Publishing Pipeline, the IIS Web Deployment Tool (Web Deploy), VSDBCMD.exe, the Web Farm Framework, and other tools can all work together to give you some really powerful and flexible deployment solutions. The problem has always been that these tools are documented individually, and if you want to figure out how to use them together then you've got your work cut out. Until now, that is :-) Over the past six months, I've been working with Tom Dykstra and Sayed Ibrahim Hashimi at Microsoft to create some tutorials on web deployment in the enterprise. I'm pleased to announce that we've now published the series, Deploying Web Applications in Enterprise Scenarios , to the website. The tutorial series is huge - over 60,000 words - and covers many different as

SharePoint: Getting Your End Users On Board

Everyone who implements or manages SharePoint deployments knows that the hardest part is getting your end users to engage with the solution and use it effectively. Consider the following, not uncommon, conversation: Sales guy: "SharePoint's on the blink again." Me: "Okay, what's the problem?" Sales guy: "I can't open a Word doc." Me: "Send me the link, I'll take a look." The link comes through, and it looks something like this: name/division name/program name/quote number/document name.docx At this point, I'll explain the problem. Basically, the sales team are hitting the file path length limit in Microsoft Office (259 characters, including the path to the temp folder on your computer). I'll remind them that they should be using content types and metadata, rather than multiple nested folders, to organize their tenders and proposals. I'll run through the benefit

Running PowerShell Scripts on Remote Machines from MSBuild

Today's tricky topic is how to get a PowerShell script to execute on a remote machine from a custom MSBuild project file. I won't go into scenarios here, let's get straight to the point. Most of the difficulties encountered in this area revolve around handling parameters, managing paths with spaces, and escaping special characters. Let's say we have a PowerShell script named LogDeploy.ps1 (it's trivial, but I basically want a test case that needs more than one parameter value). This contains a simple function that writes a single-line entry to a log file:   function LogDeployment { param([string]$filepath,[string]$deploydestination) $datetime = Get-Date $filetext = "Deployed package to " + $deploydestination + " on " + $datetime $filetext | Out-File -filepath $filepath -Append } LogDeployment $args[0] $args[1] The LogDeploy.ps1 script accepts two parameters. The first parameter represents the full path to the log file t