This article goes through some of the basics of setting up Sitecore on Azure Platform-as-a-service and using CRM Dynamics integration, Email Campaign Manager (ECM) and Sitecore Web Forms for Marketers.
Delivery server on premise with Azure module
Azure Sitecore Authoring server
Azure Multi-instance Delivery server
With the following Sitecore modules and versions:
|Sitecore||7.1 rev 130926||All servers|
|DMS||7.1 rev 130926||All servers|
|Azure||3.1 rev 130731 or 7.2||The development instance shall have this installed and be used to create & manage the Authoring and Delivery instances on Azure.|
|Dynamics CRM||2.0 rev 130731||All servers|
|ECM||2.1 rev 130731||This is to be run actively used on the Authoring environment|
|Web Form For Marketers||2.4 rev 140117||All servers|
Step 1 – Install Sitecore 7 and Dms
The overly simplified steps are:
- Unzip the Sitecore installer zip onto the dev web server and database server.
- Attach the databases on the database server
- Set-up the IIS instance to point to website root
- Change connectionstring.config to point to DBs
- Change web.config datafolder to point to the absolute path of the Data folder
- Add sitecore license to data folder
- Verify website spins up and test and edit / save / publish etc
Install the non-azure modules, again the simplified overview is:
- Install ECM as documented on Sitecore’s SDN
- Install CRM Dynamics connector as documented on Sitecore’s SDN
- Install Web Forms For Marketers as documented on Sitecore’s SDN
- Change web forms for marketers to store the connection string in the connectionstring.config file instead of the forms.config include. To do this change the formsDataProvider to be empty, like this:
<formsDataProvider type="Sitecore.Forms.Data.DataProviders.WFMDataProvider,Sitecore.Forms.Core" />
and then add the connection string to the connection string configs with the name “WFM” – like this:
1 2 3
<connectionStrings> <add name="wfm" connectionString="user id=sa;password=***;Data Source=.\;Database=test_wffm" /> <add name="core" connectionString="user id=sa;password=***;Data Source=.\;Database=test_Core" />
- Check that all the modules work locally from the development site – ie the CRM users are populated, ECM sends mail correctly and a simple web form can be created and used. Done!
- Make the changes for the Sitecore Email Campaign Manager (ECM) on Sitecore Azure PaaS, detailed here.
- Make any other changes to modules that use Session state and make sure all Session objects can be serialized, as this is required on Sitecore Azure.
Step 3 – Install Azure module
Tee Sitecore Azure module is an add on that allows single-click deployment of Authoring and Delivery instances to Azure. The module is pretty easy to install, but there is a little bit of configuring that needs to be done. Here are the steps:
- Open an Azure account. We have MSDN membership and this has Azure credits that come in handy for development and proof-of-concepts using Sitecore Azure.
- Download the SDN getting started with Azure and read the prerequisits: http://sdn.sitecore.net/upload/sdn5/products/azure/310/getting_started_with_sitecore_azure_310-a4.pdf
- The following tools need to be installed on the develpment server and can be found on MSDN:
- SQLSysClrTypes.msi (X64 Package) (search for SQLSysClrTypes.msi)
- Microsoft SQL Server 2012 Shared Management Objects (x64)
- Microsoft System CLR Types for Microsoft SQL Server 2012 (x64)
- Shared Management Objects.msi (X64 Package) (same link above)
- Windows Azure SDK version 2.0
- Note that a Sitecore environment file needs to be requested from Sitecore Cloud Services team, and this can take 48hrs to receive – so do this early using this link: http://sitecoreenvironments.trafficmanager.net
- Install the Sitecore Azure package using the Sitecore package manager. (click Sitecore, Development Tools, Installation Wizard, and then use the Installation Wizard to install the Sitecore Azure package, overwriting any existing components when prompted.)
- Once installed the following DLLs need to be added to the Bin directory – as these will be required on the Azure hosted instances:
- Microsoft.IdentityModel.dll (6.1.76)
- System.Web.Helpers.dll (2.0.20710)
- System.Web.Mvc.dll (4.0.20710)
- System.Web.WebPages.Deployment.dll (2.0.20710)
- System.Web.WebPages.dll (2.0.20710)
- System.Web.WebPages.Razor.dll (2.0.20710)
- Microsoft.Web.Infrastructure.dll. (220.127.116.11) *possibly not needed
- Open the web.config and remove the following mime type line
<mimeMap fileExtension=".mp4" mimeType="video/mp4" />
- Open the web.config and add the following to the runtime. This is needed because ECM requires MVC2 and Sitecore 7 requires MVC4. And neither version is in the deployed Azure instance GAC. And only one (MVC4) can be put in the bin folder. So this is the work around:
1 2 3 4 5 6
<runtime> <dependentAssembly> <assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35" /> <bindingRedirect oldVersion="18.104.22.168" newVersion="22.214.171.124" /> </dependentAssembly> </runtime>
- Open all firewalls to the azure database servers for ports: 1443 (not documented in SDN), 443 and 8443. This is a real gotcha and in my case caused a bit of confusion!
- Confirm that the development environment still work!
Step 4 – Configure the Azure deployment in content editor
The following table shows the desired communication between the instances and the databases.
|Development Instance||Azure Editing Instance||Azure Delivery Instance|
|Master DB||Dev SQL||Azure Editing SQL||Azure Delivery SQL|
|Core DB||Dev SQL||Azure Delivery SQL||Azure Delivery SQL|
|Web DB||Dev SQL||Azure Editing SQL||Azure Delivery SQL|
|Analytics DB||Dev SQL||Azure Delivery SQL||Azure Delivery SQL|
|Web Forms Database (WFM)||Dev SQL||Azure Delivery SQL||Azure Delivery SQL|
The steps to config this:
- Open Sitecore Desktop on the development machine. And then open the Sitecore Azure module
- Navigate to the Sitecore module.
- Follow the instructions to install the environment file ( this links Sitecore to your Azure account)
- Next create the Editing (Authoring) and Delivery environments (Cloud Services and databases). This is pretty straight forward and is achieved by clicking on the dots (Azure data centres) on the map and selecting “Add Production deployment” or “Add Editing deployment”. Here you can choose the initial number of instances (VMs) that the Azure Cloud Service will have. And there size (RAM and Cores) The deployment takes around 20 mins for an average size website (unconfirmed on bigger sites!)
- Once completed the map changes and the grey buttons are now blue! There are a few other options here on the click menu, such as:
- Browse – opens the site in a web browser
- Start – Start the Azure Cloud Service
- Suspend – Pauses the Cloude Service – but the DBs are still LIVE (and therefore clocking up the bill!)
- Swap – Lets you swap the Staging with the Production instances. This is useful if they are sharing the same databases, and can be a deployment strategy.
- Scale – Lets you scale up/down number of instances on the cloud. However you cannot increase the size of exsistingly provisioned Cloud Services (from say Medium to Large), this can only be achieved by Deleting and then recreating the environment!
- Upgrade Files – Pushes the new files (configs, layouts etc) to the cloud service in Azure
- Delete – Delete the Cloud service in Azure, but not the configs to recreate them that reside in Sitecore.
- Properties – Shows the Azure PaaS settings (all of them) in the Sitecore Content Editor
- Add Webrole – Lets you extend more Web Roles on demand
- Now select the Properties for the Editing instance, and in the Sitecore Content Editor you need to configure the databases to be correct – as in the target table above. The settings are stored at: Sitecore -> System -> Modules -> Azure -> [Deployment Name] -> ..
- From here you can see that there are “Database References” and “SQL Sets”. First of all check the SQL Sets to have the correct source (development machine SQL databases) and the correct Azure Targets.
- Next make sure the “Database References” for the Delivery and Editing instances are correct. ie the Core Database is shared – so that the Editing “Database References” for “core” points to the Delivery core database. And similarly for all the shared database (Web forms and Analytics). This can take a bit of trial (leap of faith) and error. But deleting, reconfiguring and re-creating is usually an hour cycle, so not too bad. And once setup its done for ever… or until the next project!
- Additionally here if you are installing Web Forms For Marketers – it is here that you should add the reference to the additional website as a additional SQL set on Delivery.
Alternative to step 10 – that is not quite as clean is to manually create the Web Forms database on Azure and just add this to the connection strings config:
- Use SQL Management to create a SQL script with “Convert UDDTs to Base Types” option set to “TRUE” and “Types of data to script” set to “TRUE”. This created the SQL statements needed.
- Create a new SQL database using the Azure Portal called “*WFM” for the correct server (see screen shot below)
- Open the Azure DB in SQL Management Studio and run the script created in step 1.
Web forms for marketers save actions (for Dynmics CRM) are not supported and I’ve found noway of making them work on Azure (PaaS) – other than creating them as Custom Save Actions.
There are two prerequisites for a CRM save action (for WFFM) to work that need to be understood:
- That a valid read /write CRM connection is established
- That the session state is in-proc (ie in memory not serialized to disk or using the Azure session state management). This actually only affects the editing dialogues for the Dynamics Save actions, and does not affect their actual functionality.
For this reason the CRM save actions can be seen to work on development, where session is set to Inproc; but the editing interfaces do not work on the Azure deployments. In our scenarios this is ok, as the CRM save actions are setup, configured and tested on the development instances, and deployed to the Authoring / Delivery instances on Azure – where they work fine. It’s just they cannot be managed (as they should be) on the Authoring server.
Sitecore Azure PaaS offering is really a great option and once explored for a couple of hours makes a lot of sense. I’d recommend it as a time, cost and maintenance reducing option. Great work Sitecore and Microsoft.