Please upgrade your web browser now. Internet Explorer 6 is no longer supported.
Thinking Web Solutions?
We create smart, fun, functional websites that make your web a better place.

Archive for tag: Configuration

Recent Improvements to STSADM backup

Recently there have been a few key improvements to the STSADM backup command which I have found to make life a lot easier (and safer!).

After installing Service Pack 2 and running the backup command you will notice a few subtle, but important changes:
backup

Previously it was a best practice to set the site being backed up to read only using the setsitelock command. This is something that I am guessing 95% of people never did. And who can blame them as it wasn't made terribly obvious. Fortunately the backup command now automatically sets this and lazy admins can have peace of mind.

The April CU also provided an important update to how backup and restore works, particularly with publishing sites. In SharePoint, the actual page layout aspx files are stored with some hardcoded metadata which includes the url of the site they belong to. Previously when performing a backup & restore to different farms with different URLs this could cause issues. Import/Export does not have this problem as the page layouts are recreated in the target site. The backup command has now been updated to fix this issue and this method of migrating content between farms is now supported. Note that the  June CU is now available and supersedes the April CU.

So why would you want to use backup/restore over import/export to migrate content anyway?

If you commonly use the SPSiteDataQuery class, ContentQuery webpart or the DataView webpart you rely on GUID references to lists for query commands. By default, import/export assigns new GUIDS to any lists that are migrated which will upset the queries that rely on them. Using backup/restore was an easy way to avoid this issue.

Of course it was fairly easy to write some import code using the object model and retain the GUID values. And if you still want to use import/export that is the way to go.

Installation accounts for a dev/test server

I don't particularly enjoy installing SharePoint, I've done it a million times and really it's quite a boring process. When I do end up having to install it, I generally use a simple 4 account method:

  1. Admin (SPAdmin) - Used for installation and administration of SharePoint
  2. App Pool (SPAppPool) - all web apps except central admin run with this account as their identity
  3. Services (SPService) - App pool account for central admin and the SSP service account
  4. Search (SPSearch) - Used for all search services

Generally I'm installing SharePoint for my own dev/test purposes, so this suits just fine. I think it is also fine for small scale installations or instances when the admin in charge of account creation isn't interested in creating 8+ accounts. To be honest I think a lot of the time using the 8+ accounts is a tad overkill, and people are just blindly following 'best practices' without applying them to their specific environment. But being more of a dev type than an infrastructure type I don't feel qualified to formally make that recommendation.

Even for a development server it is really important to have some separation of accounts. It is in your best interest to simulate a production scenario as best you can. Take for example if you were to use the SharePoint admin account as an application pool identity. You may have permissions to do things on your dev server (in code) that will probably have issues in a production scenario.

Tip for naming columns and lists in SharePoint

When developing against lists, column names with spaces can be rather annoying. Internally SharePoint encodes spaces with the characters '_x0020_'. This isn't the end of the world but is a bit of a pain when writing code that uses the column names. Over the past few months I have found that I got into the habit of always creating columns without the space, and then renaming them.

As an example if I wanted to create a column named 'Account Number' I would first name it 'AccountNumber'. The internal name is set only once and is based on what the column is called when it is created. After the initial creation I can then safely rename the column with the space and still reference it as 'AccountNumber'.

I have developed the same habit for naming lists. With lists I think it is even more important to not have spaces as you end up with urls that look like this: http://site/lists/my%20task%20list/allitems.aspx. This is not particularly nice to look at and may even cause problems for some search engines. This is also makes it hard to read the URL and ends up as a bit of an accessiblity negative.

You can use the exact same technique as described for naming columns.

Importing Test Users into your SharePoint environment

There are a lot of cool things you can do when working with profile functionality in SharePoint - e.g. people search, my sites, audiences, people based workflow, profile management..

But when it comes to developing and testing it can be hard to tell how well things are working unless you have a bunch of test users with meaninful profile data.

If you've ever used one of Microsofts virtual machines that come with the litware test domain, you'll be familiar with Don Funk, Brian Cox and the rest of the gang. Those are all active directory accounts with profile data including direct reports which is great for testing org charts.

So how can we get those accounts into our own AD domain?

Easy - Use the LDFIDE tool that comes with windows server. Exporting the accounts into a file and importing that file into a different domain does present a number of problems: the domain name is different, many exported fields are read only, passwords cannot be imported. I've gone ahead and solved those problems for you, so if you want to import those users into your own domain just follow these steps:

  • Download the Sample Users text file. Replace the test domain values with your own. I use DC=mossdev,DC=local. I also have all email addresses going to mossdev.com which is a local mail service. I have a catch all email account setup so that all emails to my users feed into the one outlook inbox. I have also specified an OU called Profile Accounts to keep them seperate from all of the default accounts.
  • From the command prompt run
    ldifde -i -k -f c:\sampleadusers.txt
    To import all the users, you will need to keep running the command until all users have been processed. This is because of the dependicenies between managers/direct reports.
  • Download the Update Passwords text file and replace unicodePwd with your own base64 encoded password. The password in that text file is "P@ssw0rd" which I often use for test accounts. If you are encoding your own password its important to use a unicode encoding of a string. The string value would look something like "\P@ssw0rd\". You'll only need the passwords if you actually want to log in with the accounts.
  • From the command prompt run
    ldifde -i -h -f c:\updatepasswords.txt
    to update all the passwords.

Now you should have a domain of 78 users full of profile info that you can play with.

Now I can log in as Don, create a mysite and view his profile properties along with org chart:

adimport

Random Error When Creating Site Definition Templates

Been playing around with site definitions lately and came across the most random error. I had deployed a site definition solution to my test farm and then all of a sudden I couln't access central admin. The error was:

"Exception occurred. (Exception from HRESULT: 0x80020009 (DISP_E_EXCEPTION))".

This didn't mean much to me and google suggested that I rebuild my site collection. In the end I fonud that there was a problem with my WEBTEMP.xml file.

I Had added a site template configuration like this:

<Configuration ID="1" Title="Base Publishing Site (Hidden)" Hidden="True" />

Which looks ok to me and I have seen a few samples that.

The missing element was the ImageUrl. So what I should have is:

<Configuration ID="1" Title="Base Publishing Site (Hidden)" Hidden="True" ImageUrl="/_layouts/images/blankprev.png" />

I'm wondering if this is something that has changed since SP1. If you look in the SDK you can see that ImageUrl is specified as Optional (http://msdn.microsoft.com/en-us/library/ms476942.aspx).

Easy way to find a ContentTypeID

This was bugging me for a while today, was trying to infer a contenttype's id using PowerShell until I noticed that it was in the URL of the content type definition. So the easiest way is to just navigate to the content type in the site content type gallery and just scrape the ID out of the URL:

ctype

Change a SharePoint web application URL

UPDATED Feb 5th:

Just noticed that if you install SP1 for WSS there is a new STSADM command called renamesite.

Check out the details here:

http://technet2.microsoft.com/windowsserver/WSS/en/library/aeb73d9b-1734-4a62-9bbb-f092ee4f58e11033.mspx?mfr=true

This seems like it should be an easy task, but always makes me think for a few minutes before I work it out. Here are a couple of simple steps to show you (and me) how its done.

1/ Open up central admin and browse to 'Alternate Access Mappings' found under the operations tab.

aam

2/ Click the 'view' drop down on the top right of the URL list and select 'Change Alternate Access Mapping Collection'. Then select the web application with the URL you would like to modify.

aamselect

3/ Select 'Edit Public URLs' and change the URL's for any zones necassary. Although the concept of zones is more semantic than anything, they do represent the different URL's a web application may be accessed by (and should suggest a use eg intranet zone for an intranet web app).

In my example I am changing http://wsstest to http://wssfun.

aamzone

4/ The final step is to update IIS to reflect the changes. Open up IIS manager (start | run | inetmgr) and browse to the web site that corresponds to the zone you updated. Right click the properties, select the web site tab and click advanced. Now change the host header to the new value.

aamiis

The web application should now be using the new URL.

Problems after installing MS Office Project 2007

Some of my clients have noticed a few bugs after installing Project 2007. It seems that Office 2007 doesn't play that nicely with Office 2003.

I found a fix tucked away in some MS forum, thought it should be shared.

The symptoms are:

1)

When trying to view a list in datasheet view you receive the following error:

"The list cannot be displayed in Datasheet view for one or more of the
following reasons: A datasheet component compatible with Windows SharePoint
Services is not installed, your browser does not support ActiveX controls, or
support for ActiveX controls is disabled."

2)

Sometimes when opening a document in SharePoint the browser crashes and you get the following error:

IEXPLORE.EXE - Application Error

The instruction at "0x30cb0c0f" referenced memory at "0x00000000". The memory could not be "written".

Click on OK to terminate the program

project_error

There are two simple fixes that can be made to resolve these issues:

1) Open an MS Office 2003 application and from the help menu select detect and repair.

2) Go to add and remove programs, find MS Project 2007, select change, select repair and reboot.

Exercise caution applying the SharePoint Daylight Savings Hotfix

After applying a number of successful New Zealand Daylight savings hot fixes we came across one that brought down an entire SharePoint farm. The patch seemed to install ok but the SharePoint products and technologies wizard threw an error around step 9.
Bascially the issue was that it left all the content databases in an inconsistent state. This left us in a very dangerous situation as it is not possible to uninstall the hotfix.
The Event Viewer showed an error that suggested the version of SharePoint recorded in the Content DB was 3.0.149.0 but that it was expected to be 3.0.150.0.
To get things going again I updated the value in each content database and did an iisreset. This operation would of course be completely unsupported by Microsoft.
The basic message here is to apply the hotfix with caution as things can go horribly wrong.
Recommendations:
If possible perform after hours or plan an outage period
Backup all related SQL databases
Quiesce the farm before applying
Install the operating system daylight savings patchs prior to upgrade
Log in as a Farm Administrator before running the hotfix and SharePoint Products and Technologies Wizard (Very important as this may affect DB access)
Resources
Note that you do not have to install the SPTimer job hotfix (kb938663) if you install the SharePoint/WSS daylight savings hotfix (kb941422).

Restoring a content database to a new server

This is a pretty basic procedure, but I have seen it gone wrong so many times I thought it worthy of a quick blog post.

The process is as follows:

  1. Take a SQL backup of an existing content database
  2. Restore SQL backup to new server
  3. Create managed paths to match the structure on the previous server ** important (see below)
  4. Run the following stsadm command to attach the content db.
  5. stsadm -o addcontentdb -url [WebAppURL] -databasename [RestoredDBName]

**

Step number 3 is where the problems all occur. When the addcontentdb command is run, the configuration database will be populated with all the sites in the content database. They will be populated according to the path structure in the previous server. Therefore your sites will not be restored if the managed paths do not exist.