Monday, February 20, 2006
Friday, February 17, 2006
The client has a configuration that - while probably not common - is not absolutely crazy either.
Basically, they have a Virtual Server, and have multiple site collections underneath it, one for each project. To simplify backups, they have decided to have a separate Content Database for each site collection.
No problem - STSADM includes the CreateSiteInNewDB command. This will add a new content database to our virtual server, and set up our new site collection within it. Done and dusted.
But then the client peeked inside their WSS configuration database and noticed that some site collections were using the wrong database. So Project D was in Database E, and Project E was in Database F. This is not good, because they use SQL Server for their backup and restores. So when then think they are restoring Project E, they are actually rolling back Project D.
How did this happen? After some investigation, it turns out that the STSADM Restore command doesn't really care which of the virtual server's content databases it restores to. You can't force it to use a particular database. So although Project D may be in Database D prior to your restore, SharePoint, in it's infinite wisdom may decide to put it into Database E after the restore.
Microsoft reckon that this is "by design", but it definitely sounds like a flaw in logic to me. We are planning to get around this issue by manipulating the Databases table before and after the restore. Basically we will update the SiteCount values to contain the SiteCountLimit value prior to the restore, and then set them back again afterwards. This should ensure that SharePoint can only use the existing content database for a restore.
Microsoft have just published information to their web site on what applications will be included in each of the Office 2007 bundles. They will now have an Enterprise and Professsional Plus bundle, along with their Professional, Small Business Edition, Standard, Home and Basic.
They have also released estimated retail prices for each of these editions. While the page lists the server products, no pricing is provided for them. However, it is interesting to note that there isn't a separate SPS + CMS edition. There is a separate server product for online forms - Microsoft Office Forms Server.
Thursday, February 09, 2006
However, I was reading recently that Microsoft are updating their Software Assurance licensing agreement. A number of changes are coming into affect from March 2006.
A few things in particular caught my eye. One is the Home Use policy. This allows employees to install copies of MS Office desktop products at home. Imagine - access to the latest and greatest Office 11 and 12 features from your home PC. It will be like Christmas all over again!
The other interesting amendment is the cold backup licensing. This means that you no longer have to pay for a separate license for a disaster recovery server. The gotcha is that the server must be turned off - i.e. "cold" - until the disaster occurs. You can power it up occasionally to confirm that it is all working, and to perform updates to the environment, but it can't be "warm" - i.e. ready to go in a matter of seconds after the disaster. It also can't be used for load balancing - that would be "hot".
I believe SQL Server supports the cold backup licensing today without requiring Software Assurance. Here's an extract from the Microsoft SQL licensing FAQ:
"Failover support, where servers are clustered together and set to pick up processing duties if one computer should fail, is now available in Workgroup, Standard, and Enterprise editions of SQL Server 2005. Under each of these editions, keeping a passive server for failover purposes does not require a license as long as the passive server has the same or fewer processors than the active server (under the per processor scenario)."
So there you have it - rush out and purchase Software Assurance. As always, consult a trained licensing professional before signing any enterprise agreement. If problems persist, head off to bed and watch Charmed.
Monday, February 06, 2006
I use these calculated fields for grouping and filtering list items.
First day of the week for a given date:
=[Start Date]-WEEKDAY([Start Date])+1
Last day of the week for a given date:
=[End Date]+7-WEEKDAY([End Date])
First day of the month for a given date:
=DATEVALUE("1/"&MONTH([Start Date])&"/"&YEAR([Start Date]))
Last day of the month for a given year (does not handle Feb 29). Result is in date format:
&"/" & MONTH([End Date])&"/"&YEAR([End Date]))
The name of the month for a given date - numbered for sorting - e.g. 01. January:
=CHOOSE(MONTH([Date Created]),"01. January", "02. February", "03. March", "04. April", "05. May" , "06. June" , "07. July" , "08. August" , "09. September" , "10. October" , "11. November" , "12. December")