Commerce Server Blog

In last two articles, we have seen what is commerce server staging and how it works. Check below links for more details.

http://microsoftblog.co.in/commerceserver/introduction-to-commerce-server-staging-2/

http://microsoftblog.co.in/commerceserver/how-commerce-server-staging-works/

In this article, we will see what are the security (access privileges ) consideration we should consider to staging service accounts. Microsoft CS team has provided some recommendations on this. I have seen in couple of implementations, the entire stating is executed on the service account which has admin privileges, which is not recommended. Here are the set of privileges a staging Service account should have.

Here are the set of privileges, AD groups (css administrators and css operators accounts) should have -

Note: Since staging doesn’t do any operations on <site>_transactions, there is no need of giving access to staging service account to this database.

To make developer life easier, I have created SQL scripts which provides proper access to the service accounts.

In the previous post, I explains the core CS staging concepts and if you have not yet viewed , click below link for more detail.
http://microsoftblog.co.in/commerceserver/how-commerce-server-staging-works/

In this article, we will learn how staging works. When you install commerce server staging (Note: staging is part of CS enterprise version), a service named “Commerce Server Staging” is installed and you can see it in services MMC. When ever we start a staging project, the replication (during transit, CS encrypts data using SHA algorithm) will happen under this account credentials. So, make sure you don’t run this service under network or local account instead run it under domain account. Apart from the service, three groups are created on the server and each group has it’s own significance.

• CSS_SG: commerce server staging service group have operator access to all projects. So, the service account under which the staging service runs is to be part of this group.
• CSS_Operators: commerce server operator group have operator access to manage projects.

• CSS_Administrators: commerce server administrators group have administrative access.

The below table explains security permissions between the groups.

The users can able to access projects and routes in Staging MMC only if they are part of CSS_Operators or CSS_Administrators and make sure proper access to databases. I will explain more about sql security in my upcoming articles.

The below diagram explains how stage data is moved from source CSS server to destination CSS server.

• The staging operation starts when the user trigger project execution. Project execution can be done manually either through staging MMC or staging command line utility (CSS.EXE) or the execution process can be scheduled to run on a particular time/date.

• Based on the project name, CSS process loads information from configuration settings and initiates the process.
• Based on the destination settings, the source CSS informs all destination CSS systems about the execution so that they are aware and do the necessary imports.
• Based on setting, the data is extracted from commerce server or web folder or IIS.
• Once extract is done, the extracted data is moved to destination folders. Here Staging encryptions data using SHA algorithm so that the data transferred happens securely.
• Once the files are copied to the destination folder, the destination CSS loads the configuration and start importing data.

Commerce server staging (in short CSS), helps us to transfer and update business data and web site content from one environment to another environment.  In the nutshell, CSS provides following functionality.

• Remotely administer servers and projects.
• Replicate web site content or business data over LAN and through firewalls (TCP port 507).
• You can deploy content or data manually or on pre-determined schedule.
• Replicate IIS metadata
• Configure scripts and/or batch files to run before or after content or data is replicated.

Few things to make note of:

• Business data includes catalog schema and data, Marketing data, site terms, order configuration.
• You can’t stage/ replicate profile schema, profile data, inventory schema, order data, direct mailer job, lists and confirguration.
• All business data types supported by CSS can refresh site cache.
• Web Content, includes HTML, images, ASP.NET pages, commerce server pipelines and other files, IIS metadata.
• IIS meta data includes information about the files in the website and its configuration.
• Make sure TCP port 507 is open in order staging site work.
• Roll back feature is applicable to web content deployment only.

The below diagram explains how staging works. In CSS, we have three types of servers.

• Source staging server – this is the server from where the content & data is deployed.
• End point server – this is the server to which the content & data is deployed.
• Way point server – this server is used to relay the content & data from source staging server to end point server.

In the below diagram demonstrates how the data is moved from one environment to another environment. The CSS service can be installed on dedicated box or on all environment servers.

In order to understand CSS, you have to learn two concepts – one is project and another one route. A CSS project defines the properties of a CSS deployment and it takes few key properties like, name, type (content deployment or business data deployment) and project source (path where the data is staged). Some of the points we have to remember while creating a project.

• A project needs to be created in each CSS server involved in staging. (The above diagram, we are using single CSS server for all deployments).
• Project name should be same for all CSS servers (this will not accept special characters including space) and the properties may differ from one project to other.
• Project properties tells the purpose of staging.
• Project type must be same for the same projects across CSS servers. For example, if the project at source staging server is “web deployment” then the end point server project type should be the same.

A route in CSS signifies a path by which the data is moved from source to destination. A route will hold few properties such as route name, local directory to store the data and the destination server. As CSS project, route is also required to have few mandatory settings in order to work and they are

• A route needs to be created in each CSS server involved in staging.
• Route name should be same for all CSS servers .

Note: Defining a route is not compulsory for a given deployment. In majority of the deployments, I have seen, we have created CSS projects without routes. This is applicable if the source server can’t access the destination server directly.

In coming posts, I will try to explain how commerce server staging works, command line tools and how can we write scripts to make the deployment easier.

After periodic password update to our application service account, the staging environment stopped working. When I right click and start the project, the process keeps on aborting and in the event log, I am getting “Remote authorization failed to server hl-stage-web. Ensure the service has access to this server.” error.

With the error description, I can easily understand that the account on the source machine could not log onto the target machine but the same account is running in all environments (WIP, pre production and production environment). To temporary fix this issue, I have right clicked on the project, select properties. Click on destination server and press edit button. In the dialog box, I have explicitly provided the user name and password (as shown below). Once done, the staging service start working properly.

Later I found the root cause:  If the account user names are the same on both ends, then the passwords do not match or the account on the target does not have sufficient permissions. It may also be that the domain/server managing  logons for that remote domain is not responding. The recommendation is to ensure that security is set up correctly between the two machines and that the domain on the target end can validate logons.

Commerce server Message manager provides us to manage localized message handling. We have to follow series of steps to covert the messages to satellite assemblies. So, here are the steps we should follow.

1. Create and modify RC.XML and include your localized text and languages (you can find in %Commerce_Server_Root%\Sdk\Samples\MessageManager folder).

2. Use RCxml2Resx.exe tool to covert RC.XML file into resx file. ( You can find it %Commerce_Server_Root%\Tools folder.) The input for this tool is rc.xml file.

3. Create resources file using Resource File Generator (ResGen.exe).

4. Generate satellite assemblies by using Assembly Linker (Al.exe) command-line tools.

After adding few languages (actually I added 32 languages to the xml file), when I run RCXmlResx.exe file, you can encounter problem and tools exits with an exception (as shown below) and nothing is written in the event log.

I checked many places but the solution is not found. After troubleshooting further, I found this error is due to following mistakes.

1. I used wrong locale code . Instead of “<Language Name="en-ZA" Locale="7177" />”, I kept “<Language Name="en-ZA" Locale="71777" />”.
2. I have added wrong language locale code (in my instance, I have added “<Language Name="en-AE" Locale="1033" />”).
3. If the language value doesn’t exists but a value (message) exists in <Entry> tags.

Note: The messages language value under <Entry> tags need not be in a sequence.