Making Sense of the SharePoint World

Sep-292008

The Only Constant in Life is Change

"What's In a Name?"

MCj02972590000[1]The recent turmoil in the financial industry has got me to thinking. (And no, this isn't an article about the finance industry, or the turmoil.) What happens when something really foundational changes? How will you adapt your SharePoint environment to the new situation? How can you adapt it to the new situation?

When you are planning and configuring a SharePoint Server farm, you often take certain things for granted, or at least, have certain things pre-ordained. For example, most companies have standards in place for things like machine names and service accounts, and especially for the domain the servers live in. You follow your standards, configure your SharePoint portal with a site URL that users will know it by, and go on your way.

Well, things change. Companies merge, divisions re-align, and suddenly, you may find that your company, WidgetCo, now belongs to GizmoCorp. Reality dictates that you won't be asked to bring things into compliance overnight; however, you will eventually have to integrate your SharePoint sites with the GizmoCorp way of life.

Fortunately, most of the changes you might be expected to make can be accomplished with minimal disruption. Others will take a bit more effort. Here are the things likely to be impacted, and the probable order in which they will probably need to be addressed.

  1. Branding
  2. URLs
  3. User Accounts
  4. Windows Domain
  5. Server Names

Of course, this assumes that GizmoCorp likes the WidgetCo intranet and Internet presence well enough to want to keep them. You of course have made this a foregone conclusion by making them indispensable resources to your users and clients... :)

Branding

Most acquiring or reorganized companies want to stamp their new identity on things right away. In the beginning, it might just be adding "a GizmoCorp company" to the banner, but eventually they are going to want things to match the marketing department's standards. Fortunately, if you have followed best-practices in designing your site, re-branding SharePoint while leaving the content intact is pretty easy, and very well documented. You shouldn't have any problem here.

URLs

This is almost a subset of branding. If you've rebranded WidgetWize to GizmoZone, having your users type http://widgetwize to get there isn't going to earn you any points with the management. Again, SharePoint's native functionality comes to the rescue. You can easily make your site respond to any name you like with "Alternate Access Mappings". Or any set of names.

That last is important. Even once you have changed your site's primary URL to http://gizmozone, you will probably find that people have created lots of "hard coded" links to pages in http://widgetwize. To just change the name without leaving the old URL would break all of those links. At some point after the conversion, you will want to search for pages that still have links to http://widgetwize and have them updated to the new namespace - or better yet, make them root-relative (i.e. start with just a slash "/", rather than the site name.)

Don't forget, you need to have your internal DNS configured to direct all appropriate site names to your SharePoint Web front end server's (or load balancer's) IP.

Long-term Maintenance Tip: Whenever possible, advise your users to make manual links within a site relative to the current page, or the site root, rather than using the full absolute URL.

User Accounts

Once the information is flowing between the "old" and the "new" organizations, a tighter integration of user management is likely. The networks will be connected, and "Trusts" will be established between the companies' domains. But that's just the first step. Eventually, there will probably be an account consolidation into a single domain. Unfortunately, all of your users will have their permissions assigned in SharePoint via their original accounts. Once they get moved onto their new account, how will they access their SharePoint content?

You need to make sure that, as part of the domain migration process, you take SharePoint into account. SharePoint has an API that allows you to rename a user's account, and have all of their permissions remain intact under the new name. You can access it through custom code, or via an STSADM operation. operation is called "migrateuser", and has the following form:

stsadm.exe -o migrateuser
           -oldlogin <DOMAIN\name>
           -newlogin <DOMAIN\name>
           [-ignoresidhistory]

This command ONLY changes the windows user account associated with the SharePoint account. It does not change any of the metadata or profile information associated with the user. If that also is changed as part of the domain move, you will need to do a crawl of AD to retrieve the updates (for MOSS).

Service Accounts and Windows Domain

Once your users are moved, or possibly even before, you will probably be asked to move the SharePoint farm into the new domain. This is where things get a little complicated. Not because it is hard, but because it is tedious. There are (potentially) lots of accounts used by the various SharePoint services. If you do things in the wrong order, you can potentially end up with major headache trying to straighten things out. In general, here's how you should prepare to move SharePoint into a new domain:

  1. Establish a two-way trust between the old and new domains.
  2. Test. Make sure users in the new domain can see SharePoint, and users in the old domain can see resources in the new one.
  3. Create service accounts in the new domain with permissions to match the accounts currently used by SharePoint.
  4. Assign the new accounts to their respective services in SharePoint. (SharePoint MVP, Eli Robillard, has an excellent article on that process, and cross-references a good Microsoft KB article which includes a script to automate the process...)
  5. Test. Making sure everything still works. Do it after each account change in Step 4.
  6. Make sure any other services on the servers also have accounts in the new domain! (This is an easy step to forget...)
  7. Join the SharePoint servers to the new domain.
  8. Test again.

Now, if the two-way trust is fully functional, it is possible to change the domain before you reassign the accounts, but that opens you up to a more difficult situation. That's because if the old domain's service accounts can't be reached for some reason, the whole thing comes tumbling down. On the other hand, if you are changing your accounts one a time as described, it is easy to revert to troubleshoot the problem.

Server Names

If you are lucky, you won't ever be asked to rename production application servers - of any kind, not just SharePoint. There are just way too many (sometimes surprising) things that can get messed up. Unfortunately, sometimes "rules are rules", and you must rename your SharePoint servers to comply with some policy. If the worst happens, and you must do so, there is a relatively straightforward STSADM operation that can tell SharePoint about it - "renameserver". Like migrateuser, the syntax is quite simple:

stsadm.exe -o renameserver
           -oldservername <oldServerName>
           -newservername <newServerName>

This makes the appropriate updates to the Configuration Database. You should run this command immediately before performing the actual server rename operation in Windows. Of course, nothing is that easy. While this command updates the Configuration Database, it doesn't make any other changes to your system. For example, you may have other services on the server that need to be updated, or there may be references on other machines to the old name. These are beyond the control of SharePoint.

In addition, this does not affect any links in your Start menu, or within SharePoint's content databases. If you rename the server Central Administration is hosted on, for example, you may have trouble accessing the site. Make sure you set up Alternate Access Mappings (just like setting URLs for the content sites) to the Central Administration web application (also for Shared Services, if appropriate for your environment) for both the old and new server names before you begin the rename process. In addition, you will need to manually edit the link to Central Administration within the Start menu to reflect the new URL.

Conclusion - Planning for Change

The only constant in life is change. Even the most stable company can decide to rename itself for a new generation. There are many reasons you may be asked to make fundamental changes to an existing SharePoint environment. In addition, the information you gather to prepare for an environment migration can also be used in a Disaster Recovery scenario. In a worst-case situation, you may find you have to bring your configuration back online in a new domain, or restore into an environment where your names will conflict with with existing servers.

By understanding the things that may need to change, and how these changes work, you can have a head start, and avoid the panic that can strike the unprepared.


Published: Sep-29-08 | 1 Comment | 0 Links to this post
Tagged as: Administration, Governance, SharePoint

Sep-222008

First, Do No Harm

image When I was speaking at the Wisconsin SharePoint Users Group last week, someone asked me: "How do you know when to choose SharePoint Designer or Visual Studio for a particular change to a site?" I explained that I had a sort of "Hippocratic Oath" for SharePoint customization. In essence, it involves not making changes any more complicated than they need to be in order to achieve the design objectives. The ever popular "KISS" principle - Keep It Super Simple. (Yeah, I know, there's another breakdown for this acronym, but I think this is a little nicer.)

So, here it is:

The SharePoint Customization Hippocratic Oath.

First, Do No Harm

Use the Product: Don't customize where SharePoint already does what you need.

Do it with Style: Don't build a Master Page when a CSS theme will suffice.

Take the Data View: Don't build a binary web part when a Data View or Content Editor can do the job just as easily.

Master It: When you do need to make major changes to the layout of your pages, customize the Master, but don't throw the baby out with the bath water.

Feature it at Staples: Don't build a Site Definition when you can achieve your goals with Features and Feature Stapling.

The Definition of Success: If you must use a Site Definition, understand the ramifications.

Now, I'll talk about each of the points in a little more detail.

First, Do No Harm

If it isn't broken, don't fix it. Consider why you want to make the change. Are you trying provide a function your users are asking for? Do you need to meet some corporate guideline for branding on this site? If so, fine. Go on to the next step. Or are you just trying to change something "to be different" or "because you can"? Just don't do it! SharePoint works pretty darned well, right out of the box. Which brings us to the next principle:

Use the Product

As noted in my article, Your (Share)Point of View, SharePoint has a lot capability and flexibility. Before you go building new functionality, make sure SharePoint doesn't already have a feature that performs that task. You can add logos to pages, change colors with several existing Themes, build custom menus, re-arrange components, manage content, and all sorts of other things right from the Web-based User Interface. Don't re-invent the wheel. Use what's there.

Do it with "Style"

Ok, the existing themes can leave something to be desired, especially if your marketing department is insisting that the top banner be "Pantone 321". Now it's time to open SharePoint Designer. You're still not hacking pages apart, or worrying about chasing "Ghosts". You want to take advantage of SPD's CSS editing capabilities. You can do a lot with CSS. Not just colors, but fonts, sizes, background graphics, and lots more. Although the default Master pages used by SharePoint make using CSS for positioning a bit problematic, you even still have some flexibility there.

The big thing is, unlike Master page customizations, anything you do with a theme's CSS can apply to every page in your site - even those in the troublesome _layouts folder. Even if you do ultimately need to go to the next level with a Master page, by starting with a CSS Theme, you can make fewer Master changes, and thus minimize the visual shock your users would experience when those _layouts pages come to the surface.

Take the Data (Point of) View

Get to know the SharePoint XSLT Data View Web Part. When it comes to easy, powerful, customization, the Data View is the cream of the crop. Graphical menus? Yep. Mash-ups with external data sources? You got it! The Data View in SharePoint Designer can save you hours of coding when it comes to in-page functionality. (Oh, and the Content Editor Web Part is no slouch, either!)

"Master" It

When it comes time to totally change the look of SharePoint, the only way to go is to build a new Master Page. Once more, the tool of choice is SharePoint Designer. If you're doing a public facing web site, you can start from scratch, and drop in your SharePoint functionality only as you need it. But if you are doing an Intranet portal, you should keep as much of the "stock" SharePoint as you can. Again, start with the theme CSS, and then start working on your Master page. You might find you don't need to change nearly as much as you initially thought. There are a lot of standard SharePoint components used in the default Master page. Learn about them, and don't throw them away when you build your own Master pages.

"Feature" It at "Staples"

When you finally reach the point where you just can't implement the functionality you need through Themes, the Data View, or custom Master Pages, only then do you need to reach for Visual Studio. But even here, there is a hierarchy of needs. You don't need to come out of the gate with the "big guns" - a new Site Definition. In fact, that should be pretty close to your last resort. Instead, go for creating Features. Features can be added to sites as needed. You can even force their deployment through Stapling them to existing Site Definitions. Features can be activated, deactivated, and even upgraded, on existing sites.

The (Site) Definition of Success

None of this is to say that Site Definitions are obsolete, or should never be used. You just need to be aware that this is a very fundamental construct. Once you build a site from a site definition, you cannot change it to a different definition later. You can still tweak it with additional features, but you can't change the "kind" of site it is. It will not be a "SharePoint Team Site", easily and transparently upgrade-able. It will be an "Acme Group SIte", or whatever you have called it, and you need to plan for its entire life-cycle (Much like adopting a puppy). There may be extra steps in the upgrade process, for example (though, at this time, we don't know what those steps might be). You may have trouble getting support if the person who created the Site Definition moves on to greener pastures. This may be worth it for your environment, but it is something you need to take into account.


Published: Sep-22-08 | 2 Comments | 0 Links to this post
Tagged as: Design, SharePoint, Governance, Administration, Customization

Sep-32008

Your (Share)Point of View

Note: This classic post has always been one of my most popular. I'm including it here for your "enlightenment"...

SharePoint is big. Really big. So big, in fact, that it is very hard, some might say impossible, for any one person to fully comprehend. Now, I wouldn't go quite that far, but I will say that many people approach SharePoint in much the same way as the blind men approached the elephant. 

What? You haven't heard the parable of the blind men and the elephant? Well, sit back and relax, while I digress a moment…

ElephantOnce upon a time (don't they all begin this way?) Anyway, once upon a time, there was a group of blind men traveling down the path to enlightenment when they encountered an elephant and his trainer. The elephant was totally blocking the road, so the trainer said to the men, "Please wait, while I move my elephant out of your way."

"We have never met an elephant before," the men said. "May we touch it so that we may know what an elephant is?"

"Of course!" The trainer said, and the men approached the elephant.

The men reached forward as they walked, and each spoke to the others according to what they perceived.

The first man walked into the side of the elephant, felt up, and down, and side to side and exclaimed "I have encountered a wall. An elephant is a large, warm wall!"

The second man had walked up to the elephant's leg. He said "Are you crazy? This is no wall, but round, and sturdy, like a tree trunk, or a pillar. An elephant is a kind of tree!"

The third had encountered the trunk and said "You are both wrong. An elephant is a large serpent, like a python, but without bones!"

The fourth, who had felt the elephant's ear, believed it to be a piece of canvas, while the fifth was equally convinced by his encounter with the tail that an elephant was a brush for cleaning things better left unmentioned in a family blog.

The blind men argued with each other, each believing that his view of the elephant was the correct one. They were about to come to blows when the trainer, who was also very wise intervened: "Gentlemen, please, you are each right, in your own way, but also all of you are totally wrong. An elephant is neither wall, nor tree, nor serpent, or even bottle brush. It is a vast creature of many parts, some of which resemble the familiar things you have perceived. But to truly understand the elephant you must expand your perception, and approach not just the piece you are familiar with, but the entire animal."

With that, the trainer had moved the elephant from the path of the blind men, who had just taken another major step on their journey toward enlightenment.

Now, back to our regularly scheduled blog post…

What you see when you first approach SharePoint will vary considerably depending upon your experience and what you expect to find. You might, as a network administrator, first see SharePoint as a stand-alone application. And you would be right. SharePoint provides a great "out-of-box" experience, with tools for file sharing, team collaboration and communication, project management, all wrapped up with easy distributed administration functions.

As a business analyst, you might say "Wow! Look at the all of the tools I have to aggregate knowledge and business intelligence" You see SharePoint as an integration portal, able to give you windows into data scattered throughout your organization through search, through the BDC, or even Forms and Excel Services. And again, you would be right.

As a software developer, you might see SharePoint as a rich application platform. Almost like an extension of the .NET framework, with its own API, an extensive object model, built-in modularity, and extensibility. Also correct!

SharePoint is all of those things. And more. But to treat SharePoint simply as an application, or BI aggregator, or development platform is missing the "Point". What if I told you that you could, in your integration portal, add connections between your views and information already within SharePoint so you can filter results dynamically, customize the look, enter in new information, and notify your team of changes, all without writing a line of code? Or by adding a little custom code behind the scenes, alter the experience to the point where you might never know you were using SharePoint? This is all possible, just shifting your mind set.

As an administrator, look at the SharePoint API and object model to see what you can do with just a little programming (e.g. my previous blog entry regarding "The SharePoint Nobody Sees")

As an analyst, don't just look at how SharePoint can connect to your data, but how you can connect the pieces of a page together to coax even more intelligence from your knowledge.

As a developer, familiarize yourself, not just with the object model, or the web service API, but with the front-end customizations that are available before you even open Visual Studio. Web part connections, Data web parts, and the WPSC are just waiting to do your bidding!

Like the elephant in the story, SharePoint is a beast of many parts that each can, at first glance, look complete. But to truly understand it, you must venture outside your comfort zone, and see how the parts connect and relate. Only then can you say "I have seen the elephant!"


Published: Sep-03-08 | 0 Comments | 0 Links to this post
Tagged as: SharePoint, General, Classic