Month: March 2009

So a few different folks in the SharePoint community have mentioned that they’re huge fans of Balsamiq, and we’re not talking about vinegar. Balsamiq is an application built upon the Adobe AIR framework that allows for rapid development of mockups – typically of web based applications, but can be used for mockups of such technical systems as the iPhone. A quick mockup I did last night using their demonstration copy left me with a definite interest of using the product more regularly when developing quick designs.

In this case, I’ve developed a quick SharePoint-esque mockup of what the swashbuckling developers at Pirate Nosh* would want to design their site to look like. Not only was it extremely easy to drag and drop components onto the page, but I was extremely impressed with the folder tree component which can be customized quickly and easily without having to do a significant amount of “nudging” of graphics to the left or the right or copying and pasting and arranging as you might do in something like Visio.
Overall, a great product by Balsamiq Studios, definitely applaud their product and hope to be using it more often in my daily work when designing interfaces to better help gauge what’s on the page.

Joel Oleson, John Ross Jr. Jennifer Mason and Paul Culmsee have developed a whitepaper on behalf of Microsoft on the topic of “SharePoint Collaboration Service Governance Plan”. The document provides an outline of the administration, maintenance and support of an MOSS 2007 deployment.

Great document that definitely gets at the heart of the matter with regard to roles and responsibilities and developing a plan for a deployment. While most documents released from Microsoft have little fluff in them, this document I would say has zero fluff and is like a laser beam, carving out a path to success. Definitely worth your time to read, available at:

Everyone’s getting in the game of cumulative updates… even the Outlook team, releasing patches pre-SP2. Looks like the Outlook product team has been fairly busy with fixes and improvements with the Outlook client.

Probably the biggest thing for me is the Shutdown speed. While the process may continue to run in the background for synchronization purposes, over all I’ve noticed that it disconnects from Exchange more elegantly and closes down rather than lingering waiting for a connection to disconnect.

So it would seem that the product team decided to release a second iteration of the February Cumulative Update “Uber” edition. This time including some sweet functionality to address Document Lifecycle (DLC), Infopath Forms Services (IFS) and Excel Calculation Services (XLSRV).

Fear not if you already installed the first iteration of the February Cumulative Update, this should be a fairly painless process.

The WSS Update information for the update (KB 961755) seems somewhat misleading pertaining to features added since it merely states that the Hotfix contains the following updates:

So I figured I’d throw my two cents in on the topic of documents and whether or not we’re going to see them sail off into the sunset. So far the gauntlets have been thrown down by SharePoint Welterweights Joel Oleson and Spence Harbar.

I’d have to disagree with the original thesis, I don’t think that documents are on their way out. I do however think that the way that information is generated is changing – documents however will still be around for portability and as a storage container for the objects for which they consist of.

I’m pretty certain that we’re going to continue to have separate, partitioned documents stored as files that consist of images, information and other forms of media on a particular topic. This container will be saved as a document with a particular format dependent on what the file’s purpose is (presentation, image, technical specification, memorandum, etc.) primarily for portability and to separate the content (perhaps as a matter of record).

While it might seem that Office Online will eventually open up an online Word editor and Google Docs continues to bolster their online editor, both of these systems require an account within the identity management store (either Microsoft or Google) to access the documents.

Lack of identity federation alone will be part of the reason that documents continue to persist. Many large organizations are struggling to collapse their domains and identity stores to a single system, federation is probably the last thing on their mind. Why is Federation of identity important? Merely for the reason that if you are not able to access the data the you seek in a Wiki page on someone else’s system, more than likely you’ll request the information be sent in a document through a means such as e-mail.

Furthermore without a specified document type, how will different applications be able to differentiate their files from any other? Perhaps the applications will be intelligent enough to read through definition files and figure out which files are editable by their schema. This in itself would be quite processor intensive for the document browser to read through all definition files – it becomes even more difficult in a client server environment over a WAN.

Additionally, as Spence mentions over in his blog entry, you’re going to have to have some way of versions maintained – Wiki’s can’t really do that for something like a Visio diagram or a mindmap, can they? Not quite – or at least not yet. Last I checked each version of a Word document, even in the new DOCX format on SharePoint requried a complete copy be stored in the version history, not just the delta.

I agree that it would be more helpful to have Wiki’s for document collaboration, but this information eventually needs to be published to some format that can be sent to another party. However for Wiki’s to be useful for that document collaboration, hopefully they’ll become more flexible and have greater support for things such as MindMaps, Technical Diagrams and Specifications, and images.

Additionally, consider this – without a document to pass along to another party, how am I going to open up my portal and Wiki system to the world? How am I going to maintain a source as authoritative? If I publish my document out in a format that can have an iFilter reach into it, then it can be parsed by a search engine. Additionally, it can have some sense of non-repudiation and authenticity if it’s signed with a digital certificate.

Bottom line of my rambling, I don’t think it’s the end of documents anytime soon. I do think that they’re going to be re-engineered a bit more to be more flexible. Pretty cool what happens when you open up a docx or pptx using WinZip to see it’s text based innards. 🙂

So I realize that this article is about two years too late, but the question still comes up from time to time, so I figured that I might as well post it.

Situation: You find yourself in a quandary without the use of a third party tool from AvePoint, Metalogix, Quest, Tzunami and your organization just merged with another… and you’ve got site data that you need to move. Sure, sounds easy, but it’s a pretty rough job that requires planning.

Courses of action that you might proceed down:

First option that comes to mind would be to perform a content migration through the attaching of content databases onto a dev server in a separate web application on the destination domain, and proceeding to restore database schema permissions to the content databases so that the farm can access the data properly. This works pretty well with the exception that if you have sites that overlap sites that already exist when you’re beginning your movement of sites from the dev environment to the production environment. Additionally, all user permissions need to be reassigned – so you end up running through stsadm in a batch script fashion.

Second option that comes to mind is to use Gary Lapointe’s export and import files stsadm extension. These extensions go above and beyond what the out of the box stsadm tool provides and fulfills several other purposes outside the scope of this article. Using these extensions for exporting document libraries and lists, you’re able to perform a content deployment method without having to write any of your own code. Additionally, there are extensions that allow for exporting a list or document libraries schema so that you’re able to recreate site columns and content types within the destination list. The only potential issue that would arise would be recreating or migrating all site permissions.

Third option with potential for small organizations – save site as template with content. Unfortunately this can only grow so big before it becomes unwieldy and templates stop working.

The fourth option, which to me seems to be the easiest as long as you’re dealing with a fairly vanilla SharePoint installation that doesn’t have customized site definitions, is to follow the approach of using standard stsadm tools and a bit of elegant batch file hacking.

Next, you’ll want to ensure that the security groups are how you want them – moving them from one site collection to another through a site isn’t always as pretty as you might hope. Sometimes it’s best to go in and re-create them in the new site collection rather than bringing over what was old, using them as a reference before toasting them.

Lastly, you’ll need to migrate the user permissions from domain A to domain B.

To do this, again, pretty trivial, just a little stsadm’ing. I’d recommend creating a spreadsheet in Excel and then exporting it to a text file to run as a batch so that you end up with something like this:

This method takes the user, reassigns them to a temporary user and then the TempUser is migrated to the user account in the new domain. This is not always necessary, however I’ve come across a few instances where using a TempUser is recommended to ensure that the migration occurs properly.