Getting Partial and Complete Full Farm backups to restore properly on 2007

This is my research today/this week, until I get it working and properly documented, at least on our configuation traking Wiki.

Links:

Colleagues have alluded to “The GUID Problem” wherein if you don’t take a site collection’s content database offline before restoring a copy of it to the same farm, you’ll get errors because the GUIDs will match and confuse SharePoint, so the recommendation there is that if you have retroactive data you wish to restore to a different web application/site collection while maintaining your main branch on a prod server, try instead to stand up an entirely different farm, restore to that farm, then use stsadm with the -o export operation to backup the content and then restore it again on Production.

Or better yet, don’t fiddle with Production!

Anyhow, here’s the steps I am going through to get this to work. Again, my situation is that I’m just trying to verify that a full farm backup can have part of its content (one web application’s site collections) restored somewhere else if need be.

  1. Take the full farm backup with either stsadm -o backup -directory \\UNC\path\ -backupmethod full - url http://mossdev1/ or via the Central Administration UI to do the same thing (left as exercise to reader). (Note, you need to make sure that the service account that’s running your instance of SQL Server for the back-end has write access to the filesystem/UNC Path you provide during the backup setup steps.)
  2. Copy the xml files and directory tree generated to a new farm for restore. Share this directory to make sure it has a valid UNC path. Make sure your SQL instance Service Account has full access to the share/UNC path.
  3. Check to make sure there are no failed Job Statuses for Backup/Restore on your target (restore) farm.
  4. Locate the directory where you want to/already store SQL database files (your SQL admin may already have placed this somewhere else on the server or it may go to the default: C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data. Make sure you’ve got proper permissions to write to that directory (I used a very high-level account, permissions-wise, to request the restore, and made sure that it had write permissions to the directory, but am not entirely sure that’s the correct account to configure – need more research here.
  5. Restored part of full farm (only one web application: http://mossdev1:44444/ and one Content Database: WSS_Content_Database).
  6. Because the security model was completely different for the target server from the source server, went into SQL 2005 Management Studio, connected to the proper instance, and found the Content Database (to make sure it was properly restored), opened the AllDocs table to make sure data was in there, and then edited the SQL instance’s logins to make sure that the Farm Service Account had proper rights to access the Content Database (I gave it dbo rights on the database, but you can probably get away with User rights specifically granting Connect rights within the database in question).
  7. Because the host name of the Web Application I restored is different from the VPC’s hostname, make sure that IIS recognizes the proper host header, and that you have DNS or hosts file entries that map to the proper IP address. Go into the IIS Manager, right click the Virtual Server that corresponds to the Web Application you just restored. Click the Advanced button in the Web Site Identification control group on the Web Site tab. In the pop-up box, click the entry for your port, click the Edit button, and add the proper host header value(s) to the Host Header Value text box. If you are changing DNS records, be sure to create an A and a PTR record. If using hosts files, just go to C:\WINDOWS\system32\drivers\etc\ and edit that file!
  8. Because the fact of the different security model probably kept the Content Database from being properly attached to your Web Application, go back and do that manually. Go to Central Administration, choose Application Management. Then choose the Content databases link under the SharePoint Web Application Management section. Click the Add a content database link in the title bar. On the next screen, specify the database server/instance, database name and you can probably leave the other fields at their defaults (unless your organization specifies other settings).
  9. Because of the different security model, you’ll also need to add your current login account to the Web Application’s policy. Do that now. From Central Administration’s Application Management area, choose Policy for Web Application (Under the Application Security section). Click Add Users, then make sure you’ve got the right web application and click Next. Specify the user(s) you wish to have Site collection administration, choose Full Control and click Finish.
  10. Now try out your site restore by going to the URL it should be at. If you’re not sure about that, check out your Site Collection List under Application Management for that Web Application.
  11. If you have any other issues, you may be on your own, because honestly that was enough problems to surmount for me today! 🙂

SharePoint Developer Environments (Esp. 2007)

About a year and a half ago, our petition at my current work site to create/use developer environments for SharePoint (then 2003) was punted, mostly because the requirements for dev environments are almost completely diametrically opposed to the various security and systems policies at this site. The detente when finally reached was that we could run entirely self-contained VPCs but only if they ran on our (my consulting company’s) hardware and were composed of developer licensed software licensed to my company.

Anyhow, now that 2007’s out, deployed at my current work site, and people are taking seriously the task of converting from MS CMS 2002 to MS SharePoint 2007, among other things, the need for developer environments cannot be denied, and the VPCs my company is creating for such an environment are too resource-intensive to run on our old laptops, so something’s got to give.

As such, I’m doing a lot of research about it to justify/position the arguments for such environments. In general I will have at least skimmed these links, but may not have read them thoroughly. These link dump posts are really something I do to keep track of my current research and provide pointers to those who might need them.

Basic assumptions:

  • You want one server context (IIS/SharePoint) per developer for the initial code-writing steps
    This is for non-shared resources, like web parts, maybe features, etc. Something that a single developer could conceivably do in a short chunk of time in the project.
    The reason is primarily that when you attach VS 2005 to a dll/process during interactive debugging, the step-through operations lock up that application pool for anyone else sharing the same execution context.
  • Your basic virtual machine for this kind of dev work is going to be running Windows Server 2003, Windows SharePoint Services 3.0 and Visual Studio 2005, at minimum.
    In our situation we’ll probably need the whole shooting match, because unapproved SQL servers are not allowed on the open net, and they’re unapproved if they’re not solely administrated by our DBA group. Similar injunctions apply to domain controllers and unapproved DC/AD activity, as well as simply running Windows Server 2003 on a non-server box.
  • If you are allowed to run the server type applications on the VPC and then use your host operating system (i.e. the Windows XP or whatever you’re running VPC in) to run the client developer tools against the services on the VPC, the actual recommendation is to do that instead
    So you’d have a standard VPC image that has Server 2003, SQL Server (unless you’re sharing that as a network resource hosted somewhere else – but be sure you have the permissions you need to noodle around in it if it is a shared resource), AD (same cautions apply to this as SQL Server), and WSS3.0/MOSS 2007. You’d run this in a host operating system where you’d run all your client development tools. You’d still have one execution environment per developer, but the performance might be a little better.

Anyhow, here’s a list of relevant blog entries/MSDN/Technet articles:

Some links also for software architecture/development approaches:

And some links to relevant tools:

I’ll add more links as I ID them.

Send to -> Other Location sort of works!

(Woops, had to replace the images after pixelizing out all the identifying URL and ID information from the screenshots.)

(Woops 2, apparently I have now broken the image attachments here, so maybe I have to do it all again, sigh. Will do so later – Short version is that IE7 seems to be able to copy like this only across web applications, whereas Firefox 2.0 and IE6 seem only to be able to copy from subsite to parent site (I haven’t tried the other direction yet). Issue is now active with Microsoft support. The SharePoint support team have escalated the issue to the IE team, but I have yet to hear from the IE team.)

I have an open Microsoft Support case for this, and will update when I get more information.

In a document library in MOSS2007/WSS3.0, if you use the drop-down menu on the document, you can choose “Send To” -> “Other Location”. In the following dialogue box, you can select another location to send this document to. It seems to work in both IE7 and Firefox 2.0 if you are publishing from one site collection to another, but not if you are publishing, say, from a locked down subsite to a parent site that’s more public. In that case, the Send works fine in Firefox 2.0 but not in IE7. In IE7, you get prompted for permissions no matter who you are (or at least I do, being admin up and down the tree of sites, subsites, server farms, on the machine, using the account that runs the whole farm, etc.).

So here’s the typical functioning copy process (for a copy to other location between two site collections on the same Web Application (aka IIS’s virtual server, and specifically in this case, the same port: 80).

Start the copy process:
01PX - Dropdown to Copy to Other Location in IE7 - Cross Site Collection

Specify parameters:
02PX - Initial Copy settings screen - Cross-Site Collection Copy

Confirm copy:
03PX - Copy Progress popup with confirmation (OK) button - Cross-Site-Collection Copy

Review success message:
04PX - Copy Progress Successful/Done - Cross-Site-Collection Copy

Confirm that the copy succeeded in destination document library:
05PX - Confirmation of Copy - Cross-Site-Collection Copy

In contrast, here’s the same operation NOT working in IE7 while copying a file from a locked down subsite to the subsite’s parent (and top-level) site.

Start the operation normally:
06PX - Drop down command - Copy from Subsite

Set the parameters for the copy:
07PX - Copy Screen - Copy from Subsite

The Copy Progess confirmation popup window:
08PX - Copy Confirmation popup - Copy from Subsite

Get prompted for access (click cancel after trying lots of different possibilities):
09PX - Login Prompt - Copy from Subsite

Get returned to the Copy Progress popup with failures:
10PX - Copy Progress failures - Copy from Subsite

And here, I demonstrate that Firefox 2.0 has no problem with the same operation IE7 just failed at:

Initial authentication (Because it’s Firefox):
11PX - Firefox 2.0 - Initial Authentication - From Subsite

Start the copy via the dropdown box (normal):
12PX - Firefox 2.0 - Start the Copy - From Subsite

Normal copy parameters:
13PX - Firefox 2.0 - Copy Parameters - From Subsite

No popup window for Copy Progress – you get a nice website screen instead. Same deal, though:
14PX - Firefox 2.0 - Copy Confirmation - From Subsite

Copy Progress Screen reports finished:
15PX - Firefox 2.0 - Finish status from the Copy Progress - From Subsite

Confirm the copy worked – go to the destination Document Library:
16PX - Firefox 2.0 - Confirmation that document is where it should be - From Subsite

Interesting tidbit for getting your VPC-borne development environments to run properly

This tip from Kevin Kelly (not of kevinkelly.org, btw, but my co-worker – Hi Kev!).

Anyhow, if, like us, you need to do your development in a single-server installation that’s network-isolated (either SPS2003 or MOSS2007), you may have found that there are some issues when you install and try to use some SharePoint/Visual Studio features. You get what look like network name-resolution issues and other related issues. (I’ll provide more specific error information when I next see it.)

It turns out that the Visual Studio/SharePoint features that raise the errors are using the same COM model/object and raising contention issues with the System Event Notification Service. If you stop the System Event Notification Service then the features you’re trying to use start working fine.

The problem is of course that if you disable the System Event Notification Service, your code may not log events properly to the event logs. So be sure you know whether the thing is on or off while you’re doing troubleshooting!

I’ll play with this more and try to come up with some screenshots/error messages when I get the new MOSS 2007 VPC to play with (a few weeks) that my company’s creating.

MOSS 2007 Site Definitions Links

Am now doing research on how to make Site Definitions for MOSS 2007/WSS 3.0. The main reason to do this, is as far as I can now determine (this may change) still the same reason you made one for SPS 2003.

You can use Site Templates (which are entirely different animals) within any particular top level site/site collection by installing them after the top level site is running, and then base new subsites on those within the gallery of the site collection.

In contrast, if you want a thing that acts like a Site Template but applies to the root, top level site in a site collection while you are creating the site collection for the first time, you need to have already created and installed a site definition that looks/feels/behaves the way you want it to.

Anyhow, here are the how-to links:

Workflow dev in MOSS 2007/WSS 3.0

I’m doing research into developing “simple” workflows in MOSS 2007/WSS 3.0.

This is mostly a linkdump post, but I wanted to say that the “simple” workflow I have to work with (publishing documents from a private workspace/subsite to a public parent site, seemingly cannot be accomplished with SharePoint Designer 2007, which seems to be limited to publishing from one Document Library to another within the same site.

Thus, I’m investigating how to do workflow dev in Visual Studio 2005.

Site Definition and Themes Customization Research Links

I’m doing some research into Site Definitions and Themes in MOSS 2007/WSS 3.0. My goal: Determine how similar or different the mechanisms are from SPS 2003/WSS 2.0. Answer: looks pretty similar!

MOSS 2007 server farm architecture links

All in all, it looks like MOSS 2007 server farms consist of:

  1. Front End Web Servers – (low storage, hosting IIS, SharePoint and any custom web parts/custom site definitions/templates – this is a guess)
  2. Application Servers – (high storage, hosing IIS, SharePoint and indexes for search – again a guess)
  3. Database Server – (hosting the content and configuration databases)

Sounds like MOSS 2007 is in general way more flexible and configurable in Server Farms than SPS 2003 (with its three major themes of “supported configurations”).

Don’t miss all the planning you should be doing vis a vis Server Farm Architecture as you design your environments:
Planning worksheets for Office SharePoint Server 2007

Also, the configurations of the Shared Service Provider(s) give you a lot of flexibility.

Unfortunately, it looks like most of the Technet articles are still TBD (to be written), but I found one that was decent:
Determine hardware and software requirements (Office SharePoint Server)

Also, my Systems Engineer homie at my workplace sent me a lot of very interesting seeming audio-briefing links:
TechNet Events: Supporting Materials

Creating new My Site hosts for MOSS 2007

If you should happen to recreate your SSP or your MySite host in MOSS 2007, you may find that the wizard that helped you out the first time with properly configuring your MySites host may have flown the coop and you’re left at sea about how to proceed. I know I was.

On trying to create a new My Site (for a user that doesn’t already have one), typical error messages will tell you that Self-Service Site Creation is disabled, or that there was an error in creating your personal site. Both error messages will entreat you to contact your administrator.

Here’s the full scoop on creating a My Site host in MOSS 2007 by hand from the ground up (i.e. at Web application creation on up):

Prepare new web application to take up My Site host duties:

  1. Create a new web application (e.g. http://mossdev1:25000/)
  2. Inspect Managed Paths for the new web application. You should already have:
    1. (root) - Explicit inclusion
    2. sites - Wildcard inclusion
  3. Delete managed paths:
    1. sites - Wildcard inclusion
  4. Create managed paths:
    1. personal - Wildcard inclusion
    2. mysite - Explicit inclusion
  5. End state for managed paths should be:
    1. (root) - Explicit inclusion (thanks to imsaurabh for catching this!)
    2. personal - Wildcard inclusion
    3. mysite - Explicit inclusion
  6. Create a site collection at /mysite/ managed path. This will use a My Site Host template:
    1. Choose correct web application (e.g. http://mossdev1:25000/)
    2. Title: My Site Host (doesn’t matter, really)
    3. URL: http://mossdev1:25000/mysite (no fill-in because path is explicit in managed paths)
    4. Template: Enterprise (tab) -> My Site Host
    5. Specify primary and secondary administrators.
    6. Click OK.
  7. Create a blank site collection at the / managed path to enable self-service site creation:
    1. Choose correct web application (e.g. http://mossdev1:25000/)
    2. Title: Blank site (doesn’t matter, really)
    3. URL: http://mossdev1:25000/ (no fill-in because path is explicit in managed paths)
    4. Template: Collaboration (tab) -> Blank Site
    5. Specify primary and secondary administrators.
    6. Click OK.
  8. Enable Self-Service Management. Choose from Application Management -> Application Security.

Now that you’ve created the host, here’s how to make sure it works properly in the SSP’s My Site Settings:

  1. Navigate to My Site Settings (go to your SSP’s admin pages, it’s the 3rd link in the 1st section).
    1. For form’s sake, inspect the Preferred Search Center entry. This URL should end in /SearchCenter/Pages/.
    2. Set Personal Site Services to http://mossdev1:25000/mysite/. Note that this points to the URL for the explicit inclusion path and My Site Host Template site collection you created above.
    3. Set Personal site Location into just personal. Note that this points to the URL (after SharePoint puts context to it) for the Wildcard inclusion managed path you created above.
    4. Choose the 2nd Site Naming Format: User name (resolve conflicts by using domain_username).
    5. Enable Allow user to choose the language of their personal site.
    6. Disable My Site to support global deployments.
    7. Default Reader Site Group: NT AUTHORITY\authenticated users.

Now try to navigate to your MySite link and you should be golden. Creation should go just fine.

Good luck!