Normally I'd RTFM...but where's the manual?
Let me preface this by saying I'm not a pro when it comes to Commerce Server. In fact I'm writing this...because I couldn't find any non MSDN documentation to speak of when I was trying to accomplish this task. And when it comes to task based directions the MSDN is a little lacking.
This task we're talking about here is migrating Commerce Server Applications (or migrating Commerce Server) to another machine/farm. Before I hop off the soap box let me just say that at time or writing (5 months away from 2009) there has yet to be a SINGLE (note the screaming caps) Commerce Server 2007 book published. That's pretty weak. I can forgive most publishers for not authoring any content, I mean hey Commerce Server 2007 is a pretty niche product right? But how about a little support from Microsoft Press? I'm normally a sizable proponent of MS's work and if you read this blog are probably aware that I spend a lot of time in the MS tech stack, but I can't help but think I'd get more support when it comes time to pick up this product. Working in a software services firm I'm constantly trying to quickly become deep in new technologies, and existing literature has always been a huge help. I guess you could say when it comes to this "new" release of Commerce Server 2007, I sure do wish some of the MVPs or MS Staff would step up and author something. All that's available right now are a series of books on Commerce Server 2002 and a series of pretty non-technical help files.
Making The Move
Before we go into the step by step and the tools we should first speak to why moving a Commerce Server Application would be a headache (should you choose to do it by hand). The application as far as dependencies is likely to have:
- A series of folders which contain application code (normally in a web site).
- A series of databases (Admin, marketing, marketing_lists, productcatalog, profiles, transactionconfig, transactions) the last 6 of which are per site.
- The Admin site contains machine specific entries which list out all the machines participating in the farm.
- A configured Csapp.ini file.
- A series of IIS settings.
- A bunch of NTFS Permissions.
- Any other dependencies.
Luckily there's a tool to help you make the move. Commerce Server makes use of the Site Packager which generates .pup files and helps you migrate these configuration and application settings across machines/farms. In fact the Site Packager plays a pretty pivotal role when it comes to doing any kind of Commerce Server 2007 setup. Some of the common tasks you'll use it for include:
- Setting up Commerce Server Applications.
- Adding Sites.
- Adding Applications to Sites.
- Adding Web Servers to Applications.
You can normally find the Site Packager under Start->Programs->Microsoft Commerce Server 2007->Tools->Site Packager.
Pack It Up
To pack up a site you run the Site Packager. The wizard is pretty self explanatory, you essentially choose the site you want to pack, the file you want to pack it as (choose a .pup extension) and hit next a couple times. The only odd part is you'll be asked to specify .sql files for the Profile database schema and data. You're apparently supposed to generate these on your own using the SQL Server Management Studio.
In addition to site resources, applications, and the Internet Information Services (IIS) settings that are required to re-create the Web server configurations, Commerce Server Site Packager also includes the property values from the Administration database. For example, when you package the Profiles resource, all the current property values are also packaged. When you unpack the Profiles resource, the property values are unpacked into the Administration database.
The package includes global resource pointers, but not the global resources themselves. The package recognizes the connection strings that are in the application, but does not contain the actual data in the connection string
During the application packaging process, Site Packager searches the IIS metabase on your local computer and finds the physical directory that is the root for that application. It then starts at that root directory and packages all the subdirectories in the following section into a new file that has a .pup file name extension. Site Packager preserves certain settings in IIS, such as authorizations and access permissions.
More details on how the site packager works and what it actually packages up (and what it doesn't) can be found here.
Now that you have this .pup file you can move it to the destination server, and as long as that server has Commerce Server 2007 you can unpack it. Should you choose a Custom Unpack you'll be able to choose whether you want to reuse existing IIS web sites, which database to use (should there be multiple) and some more options.
A more detailed walkthrough of the site unpacking task can be found here.
This will get you 90% there. There will likely be other dependencies that you may need to fish out of the GAC or some other place but ideally a lot of the Commerce Server noise will go away. A good way to test your migration is to target your Commerce Server "site" with the Business User Applications and ensure that you can see some data made it over the wire.
My Absolute Best,