1) What’s the Catalog Scratch Database?

The Catalog Scratch Database is a database used to store the results of the queries to the Catalog System in Commerce Server.
The majority of the stored procedures will generate a table in this database.
The runtime APIs (Search, SpecificationSearch, Query, GetProducts) use this database.

The circumstances under which the Catalog Scratch database is created are detailed in the article below.

948772    The CS Catalog Scratch (MSCS_CatalogScratch) database is created when you unpack your first site resource in Commerce Server 2007
https://support.microsoft.com/default.aspx?scid=kb;EN-US;948772

This Catalog Scratch resource will be shared amongst your Catalog Resources if you have more than one.

2) Does the use of the Catalog Scratch database have any performance impact?

We discuss this in more detail in the following article.

835984    Contention may occur if only one database file is used for the Commerce MSCS_CatalogScratch database
https://support.microsoft.com/default.aspx?scid=kb;EN-US;835984

The general rule of thumb is to have as many data files as physical processors and to have the Trace Flag –1118 enabled in SQL Server.

This helps to ensure you have the best concurrency for operations on this database.

3) How do we go about maintaining this database?

As we discussed above this database is like a scratch pad for the Catalog System queries.
The tables should be empty after the stored procedures have completed but you will still be left with the tables.

So the general recommendation is to run the CatalogCleanup.vbs tool at least once a week as discussed at the following link.

How to Delete Temporary Tables from the MSCS_CatalogScratch Database
https://msdn.microsoft.com/en-us/library/bb520958(v=CS.70).aspx

4) So, what does CatalogCleanup.vbs do?

If you opened CatalogCleanup.vbs in your favourite text editor you would see that it does 2 things.

a) Check for the SQL connection string to a site Product Catalog database.

b) Call the stored procedure ‘ctlg_DropPersistentTablesInScratchDB’ in the same database.

There is also some error checking in place to handle errors.

The next thing to note is that the stored procedure is passed in a parameter which defines it’s behaviour.

Let’s look at that in more detail.

The normal execution of the stored procedure would look like this.

EXEC [dbo].[ctlg_DropPersistentTablesInScratchDB] @DropAll = 0

GO

The @DropAll parameter defines how the stored procedure removes the temporary tables.
It accepts either 0 or 1.

If you pass 0 to the stored procedure then it will delete all temporary tables in the MSCS_CatalogScratch database the currently do not have any active SPIDs.

When you use the value 1 for the parameter this tells the stored procedure to delete all temporary tables in the MSCS_CatalogScratch database. If you use the value of 1 for the parameter then you need to be aware that this may cause the stored procedure to run for a long period of time while it tries to delete the tables. And running with the parameter value set to 1 may cause problems for any catalog functions that are actually using data in the temp tables in the MSCS_CatalogScratch and the table gets deleted in the middle of the catalog operation.

So you can now run the CatalogCleanup.vbs script on the Commerce Server machine or add the stored procedure to your existing SQL Server maintenance plans.

I hope this is useful.

In IIS 7.0 you have the ability to configure a web site to only have an HTTPS binding. In previous versions of IIS you would always have at least one HTTP binding. If you have configured a web site on the Commerce Server machine with only a HTTPS binding then the site packager may fail because because the site packager is designed to read all IIS sites configured on the server and gather some basic information on each site. One of the items that we require is the non-secure binding information.

If the site is configured to only have an HTTPS binding then the non-secure binding property will be NULL and will cause the site packager to fail.

You can use the below .vbs script on your IIS / Commerce Server machine to read the same information the site packager will read and if the script fails then you can identify which IIS site is causing the issue.

******

'The code below simulates Commerce Server Site Packager checking IIS health.
'This IIS checking happens when you click the "next" button at the first dialog of the site unpacking.
'This code helps you to find out where the check is failing.

set oNet=CreateObject("WScript.Network")

sLocalMachine = oNet.ComputerName

Set webServer = GetObject("IIS://" & sLocalMachine & "/w3svc")

msgbox "Web Server "+ sLocalMachine +" has the following Web Sites:"
For Each webSite In webServer
     If IsNumeric(webSite.Name) Then

    sName = webSite.Name
    sComment = webSite.ServerComment
    sBind = webSite.ServerBindings
    sAppPool = webSite.AppPoolId
    msgbox "Web Instance Number: "+sName+" / "+"Web Site Name: "+sComment+" / "+" Binding: "+sBind(0)
    msgbox sComment+"'s Application Pool: "+sAppPool
    Set vroot = webSite.GetObject("IIsWebVirtualDir", "Root")
    msgbox sComment+"'s Root Directory: "+vroot.path
     End If
Next

set onet=nothing
set webserver=nothing
set webSite=nothing
set vroot=nothing

******

https://cid-35c1d5410c4723e7.skydrive.live.com/self.aspx/CS2009Help/CS2009.zip

1. You will need to export your catalog schema using the Commerce Server Export Catalog tool

a. Open a command prompt

b. Go to the Program Files\Microsoft Commerce Server 2007\Tools directory

c. Enter the command “exportcatalog.exe /s:<site name> /w:<url to catalog web service> /Xsd DefaultCatalog.xsd

d. You should see the specified (DefaultCatalog.xsd) file created successfully

2. Now you need to create a Message Schema containing your exported schema file (xsd)

a. Copy the Program Files\Microsoft Commerce Server 2007\SDK\Samples\Adapters\MessageSchemas directory to a directory of your choice

b. Open the Visual Studio solution

c. Replace the original DefaultCatalog.xsd under the catalog folder with your DefaultCatalog.xsd file

d. Ensure you provide an “Assembly Key File” to the project properties to build the Message Schema library

e. Build the MessageSchemas file

f. Deploy the MessageSchemas to BizTalk Server

3. Open the BizTalk Server Administrator to ensure that your MessageSchemas have successfully been deployed

4. Add the Microsoft.CommerceServer.Adapter.GlobalPropertySchemas.dll to your BizTalk Application

a. Right-Click your BizTalk Application à Add à BizTalk Assembly

b. Click the Add button

c. Go to the Program Files\Microsoft Commerce Server 2007\BizTalk Adapters directory

d. Select the Microsoft.CommerceServer.Adapter.GlobalPropertySchemas.dll file and click the Open button

e. Select the “Add to the global assembly cache on add resource (gacutil)” option along with the “Add to the global assembly cache on MSI file install” option

f. Click the OK button

g. You can verify that it has been loaded successfully by examining the Schemas within the BizTalk Administrator

5. Now you need to create your BizTalk Orchestration project with Visual Studio

a. Ensure that you add a reference to your MessageSchema file created in step 1

b. Once again, ensure that you provide an “Assembly Key File” to build the file

c. Successfully build and deploy your orchestration

6. Within the BizTalk Administrator, define the necessary Send and Receive Ports/Locations defining the Catalog Web service as the source for your Receive Port

7. Ensure that for the Send Port you provide a Filter (Property: BTS.ReceivePortName, Operator:  ==, Value: Name of your Receive Port)

8. Enable/Start the Ports and Orchestration

9. Verify that your catalog export has been delivered to the location specified by the Send Port

The version numbers match up like this:

To increase the polling interval you will need to edit the registry. First stop the service, make the registry modification and then restart the service.

The registry key is: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\CSS\ProjectDeploymentLog\PollingInterval

Default = 5000 (stored in milliseconds)

A good recommendation on a value to use is somewhere between 30 seconds (30,000) and 60 seconds (60,000). Along with increasing the polling interval you can configure the CSS service to restart automatically by setting the recovery options to Restart the Service on failure.

The issue causing the service to crash is being investigated further and as updates become available I will update this post.

maxSearchResults:    (Optional)
    Potential values include 0 (No limit) and all positive integers 1-2147483647
    Disable Authorization Manager authorization.
    WARNING: Removing this value could allow very large search results to consume server resources.

You will edit the value in the section below. See bolded item.

<catalogWebService siteName="AutoNation2" authorizationPolicyPath="CatalogAuthorizationStore.xml" debugLevel="Production" maxChunkSize="1024" maxUploadFileSize="2048000" timeOutHours="24" enableInventorySystem="true" disableAuthorization="false" maxSearchResults="500">
    <cache enable="false" schemaTimeout="5" itemInformationCacheTimeout="5" itemHierarchyCacheTimeout="5" itemRelationshipsCacheTimeout="5" itemAssociationsCacheTimeout="5" catalogCollectionCacheTimeout="5"/>
</catalogWebService>

One note on altering the value. The notation on what value can be entered indicates that you can set the value to 0 so that all results will be returned. This is not correct for Commerce Server 2009. If you set it to 0 then the web service will fail with an exception that the property being set to a value of 0 is invalid. You will need to set a value to a positive integer as noted in the notation.

For Commerce Server 2007, there are no issues with performing a new installation on Window Server 2008 R2. However, once the installation is complete and the configuration wizard has finished setting up the initial server databases you will need to install Commerce Server 2007 Service Pack 2 to be in a supported state. You will want to complete the service pack installation before you setup any Commerce sites on the server. If you are performing an operating system upgrade to an existing Commerce Server 2007 deployment, you should install Commerce Server 2007 Service Pack 2 and run the upgrade wizard against each Commerce site already deployed and verify that all site functionality prior to the operating system upgrade.

For Commerce Server 2009, there is an additional step that will need to be performed prior to the installation. With the installation of Commerce Server 2009 CD2 it performs a check for .NET Framework 3.5 SP1 and does this check by looking for a registry key stating that it has been installed. With Windows Server 2008 R2 the framework is already built-in to the operating system and therefore the registry key showing that it has been installed is not present. There is an update that you will need to obtain to resolve the installation issue which can be found in Microsoft Knowledge Base Article 975567; https://support.microsoft.com/default.aspx?scid=kb;EN-US;975567.  You will want to obtain the update and run it against your server prior to the installation of either CD1 or CD2 of Commerce Server 2009. When you run the update it will perform a single check for the registry key and if present let you know that the update is not needed and do nothing, but if it is not present then it will add the registry entry and then exit. After the update is applied you can perform the installation of Commerce Server 2009 normally. If you are performing an operating system upgrade to a server that is already running Commerce Server 2009 there is no need to obtain the update as Commerce Server 2009 is already installed and the required components are already in place.

This is because when you use the SharePoint Commerce Services Configuration Wizard to deploy the site, it will check to see if WSS or MOSS is deployed and based on what is deployed it will choose the appropriate WSP files to deploy for the site collection. There are different versions for WSS and MOSS.

If you wish to upgrade an existing WSS deployment to MOSS you will need to back-up all of your site databases and site content, then remove the site in SharePoint Central Administration prior to performing the upgrade. Once the upgrade is complete you can deploy the appropriate site using the SharePoint Commerce Services Configuration Wizard and then merge any site customizations previously done into the new site.

The symptom:
Anonymous user add items to cart, then switch the URL from the non-secure hostname to secure hostname by an action such as going to checkout, the items in the basket will disappear in Internet Explorer 8 for the same anonymous user.

Resolution:
For code based on the Starter Site, modify the Starter Site code before you set the site_identity cookie, set Cookie.Domain= “testsite.com”.

(App_Code/SiteSecurity.cs)
________________________________________________________________
public static HttpCookie CreateUserCookie()
{
…
cookie.Value = CommerceContext.Current.UserID;
if (!isAnonymousUser)
{
cookie.Value += "/" + HashValue(userProfile.EmailAddress);
}
cookie.Domain = "testsite.com";/*Jason: this is what I added*/
HttpContext.Current.Response.Cookies.Set(cookie);
…