SharePoint 2010 Beta 2 EULA: No Go-Live Licence

There’s been a bit of confusion at work over whether the current SharePoint 2010 Public Beta (beta 2) does or doesn’t have a ‘go-live’ licence attached to it. In case others are wondering the same thing, here are the relevant sections copied straight out of the EULA when I installed it:

MICROSOFT PRE-RELEASE SOFTWARE LICENSE TERMS
MICROSOFT VERSION 2010 SERVER SOFTWARE

…

1. INSTALLATION AND USE RIGHTS.

• You may install and test any number of copies of the software on your premises.

• You may not test the software in a live operating environment unless Microsoft permits you to do so under another agreement.

…

3. TERM. The term of this agreement is until 31/10/2010, or commercial release of the software, whichever is first.

…

8. SUPPORT SERVICES. Because this software is “as is,” we may not provide support services for it.

So… no. Well maybe. There’s no go-live that comes with it, but the option to go-live if separately approved is explicitly left open, and I have been told that’s exactly what some early adopters are doing. What you have to do to get said approval is unknown to me: there was a Technology Adopter Program (TAP), which is where Beta 1 went, so they’d obviously be candidates, or maybe it’s just a standard wording.

Also any number of people have blogged complaining about the lack of a migration path from the public beta to RTM. The only public statements to this effect I can find are on the SharePoint Team Blog:

SharePoint 2010 Public Beta is now available for download

Is the SharePoint public beta supported?
The SharePoint public beta is not supported. However, we recommend looking at our resources listed above and asking questions in the SharePoint 2010 forums.

Will there be a migration path from SharePoint public beta to final release?
We do not plan to support a SharePoint 2010 public beta to release bits migration path. The SharePoint 2010 public beta should be used for evaluation and feedback purposes only.

…and in the MSDN forums (see Jei Li’s reply):

Upgrade from SharePoint Server Public Beta to RTM (in-place, or database attach) for general public will be blocked. For exceptions, we will support those who hold a "Go Live" license, they were clearly communicated, signed a contract, and should know their upgrade process would be supported by CSS.

http://social.msdn.microsoft.com/Forums/en/sharepoint2010general/thread/b9817862-fd35-413a-b018-ce5c500b6760

Which again suggests the possibility of TAP program members being supported into production with (predictably) a different level of support than a regular beta user.

Forcing Web Part pages into Edit Mode

(Before I forget again :)

Even if you've hacked about with a SharePoint master page to remove all the SharePoint chrome (including the edit button and suchlike) there are URL hacks you can use to get the page back into edit mode:

pageurl?ToolPaneView=2

(There's a few more like this, see Sharepoint Tweaks... )

...as well as the hack to get a page into the Web Part Maintanance page:

pageurl?contents=1

SharePoint: The final CM frontier

For a long time I thought Biztalk was the elephant in the room when it came to Configuration Management - specifically version control. I'm not talking here about Source Control, I'm talking from a deployment perspective - the 'deploy a given, atomic, integral version into production' problem.

For a traditional .net app (Winforms, ASP.Net, WPF, whatever) it's pretty much sorted. We've had source control integration in the IDE since the dawn of time, CCNet for years, and it's even easier to get CI going now that TFS 2008 supports it out of the box. That's not to say everyone actually does so, but it's there if they want it, right?

Databases are a bit harder, but there are lots of tools around that you can incorporate into your CI cycle, and now that Microsoft's in the space with VSTS for Database Pros (now included with VSTS Dev Edition) the barrier to entry has been dropped again (though it's still a pretty poor story in the SSAS space).

However for Biztalk things are not so rosy. You get source control at least, so you can practice a unified versioning / labelling scheme, but building the project doesn't give you all the artifacts you need to actually deploy into an environment. For that you've got to IDE-deploy to a dev BizTalk instance, configure and then at least export out the binding file (if not a complete MSI). There's NAnt and MSBuild tasks to do the building, but I've not seen anyone wrap up the whole end to end, so Biztalk deployments languish in the 'manual effort with concentration' department. A direct result of this is that integrating your code with biztalk orchestrations (via WS / WCF) is increasingly seen as a more manageable approach than embedding your code, thus alleviating / sidesteping many of the issues.

I thought Biztalk was the frontier of version management - that is until I started working with SharePoint.

I'd previously accepted that working with SharePoint using the Web UI was working uncontrolled, but I'd always imagined that real SharePoint developers used SharePoint Designer, checked things into source control and had established patterns for migrating content between development and production server instances. How wrong I was. Making my first tentative forays into 'how to do this properly' I was struck by the complete absence of any guidance. It appears this is most definitely not a solved problem, which Jeremy pretty much confirmed last night in his great RDN talk on the subject. There's tools out there to manage the problem, but they're pretty new on the block. The book, quite literally, hasn't been written yet.


This is clearly a pretty major failing on Microsoft's part. I appreciate that the main thrust of version-management with SharePoint is version-management of content rather than version-management of configuration, but clearly if they want developers to embrace SharePoint as a platform they're going to have to do a bit better. Time for a 'developers, developers, developers' rant perhaps?


It seems to be that the more productivity-orientated the development environment, the less effort has been put into establishing a viable CM story:



(You could substitute 'maintainability' for 'Ease of CM / CI' if you like: one tends to drive the other)


Clearly it's easier to diff / merge lines of code rather than SharePoint XML manifests (or Workflow XAMLs), but it's a complete abdication to leave these higher-level (ie non-codey) development environments quite so dramatically out the cold.

Surely there's got to be a better answer than using DiffDog for everything?