EXAM MB2-702 – Deploying CRM 2013 : NOTES
Kevin Crampton – 1st Jul 2014
https://www.microsoft.com/learning/en-us/exam.aspx?id=mb2-702
Replaces the earlier CRM 2011 MB2-867 installation and deployment exam.
Concentrates on the aspects of customizing that are new in CRM 2013.
Resources: Microsoft course 80539A and Planning section of the implementation guide.
Contents
CHAPTER 1: SYSTEM REQUIREMENTS & TECHOLOGIES ............................................................................... 1
CHAPTER 2: INSTALLING CRM ....................................................................................................................... 4
CHAPTER 3: REPORTING EXTENSIONS .......................................................................................................... 8
CHAPTER 4: DEPLOYMENT MANAGER ........................................................................................................ 10
CHAPTER 5: UPGRADE TO CRM 2013 ......................................................................................................... 12
CHAPTER 6: EMAIL MANAGEMENT ............................................................................................................ 14
CHAPTER 7: DYNAMICS CRM FOR OUTLOOK .............................................................................................. 21
CHAPTER 8: INTERNET FACING DEPLOYMENT (IFD) ................................................................................... 22
CHAPTER 9: MAINTAIN A DEPLOYMENT ..................................................................................................... 25
CHAPTER 10: HIGH AVAILABILITY................................................................................................................ 32
CHAPTER 1: SYSTEM REQUIREMENTS & TECHOLOGIES
Dynamics CRM can be configured as either: 1) An on-premises installation (either workgroup or server edition, see next paragraph)
2) A Microsoft partner-hosted deployment OR
3) Dynamics CRM online (Microsoft hosted)
Microsoft offers two flavours of on-premises install – the “Workgroup” edition which is limited to 5
users, a single organization and is deployed to a single machine only and the “Server” edition in which
these limits do not apply. The same installation program is used for both and it is the product key
entered during installation which determines whether it is a “workgroup” or full “server” deployment.
Note that Workgroup can be upgraded to Server edition at a later date by simply entering the product
key in the Deployment Manager. Downgrading from Server to Workgroup is NOT supported however.
A single product key is used when installing Dynamics CRM. Time-limited trial keys are available.
ON-PREMISES LICENSING
On-premises CRM has a client-server licensing model. You buy a license for the server instance and then
individual CAL (client access licenses). The course notes state that external users do not need a license
without really clarifying what that means.
Three levels of CAL: 


Essential – access to system and custom entities, SDK, activities and feeds. Used for custom
applications to connect to and use CRM data.
Basic – Adds on access to accounts, contacts, cases, leads, reports, dashboards. Used for limited
access to the most basic and frequently-used entities only.
Professional – Full access
License type restrictions are NOT enforced by CRM so you should create security roles to tidy up the
interface and stop the user seeing lots of “You do not have permission…” messages.
Access via tablet or mobile phone is part of the CAL’s – the licenses do not specify or limit the device
type used to connect to CRM.
CAL are available either for USER (you buy one license per user) or per DEVICE (you buy a license for a
machine and then multiple users can access CRM via that machine e.g. useful for a shift pattern of work
or a 24 hour call centre).
In addition to the license type each user account has an Access Mode: 


Administrative – user only performs administration of CRM and does not need access to Sales,
Marketing, Service area. This user does not need a CAL as they are a back office IT role.
Read-Write – User can read and write records.
Read – User can only read records. This options is only available for the BASIC license type.
ONLINE LICENSING
User Subscription Licenses (USL) are purchased per user per month for the right to use the CRM service.
Essential, Basic and Professional levels still apply.
The course and exam seem to pre-date the Spring 2014 CRM release and the introduction of the
Enterprise license so I do not anticipate any questions on that.
1 Dynamics CRM server and 5GB storage are standard and extra instances and storage are automatically
added as extra USLs are purchased or can be purchased separately without adding extra USLs.
BEHIND CRM
The technology support CRM includes: -








Microsoft SQL Server – 2008 or higher is needed and SQL Server must be installed and licensed
already e.g. CRM does not include it. There is no direct access to the database tables, all data is
delivered by filtered views which apply the security model. SQL Server can be on the same
machine as CRM, in a cluster or on a different server.
SSRS – SQL Server Reporting Services is the default reporting solution. SSRS can be on the CRM
or SQL machines or elsewhere. You must install the Reporting Extensions for CRM to SSRS.
IIS – Internet Information Services 7.0 or later is required to deliver the web interface of CRM.
You can create the website placeholder for CRM before you install CRM or let the deployment
manager create it for you.
AD – Active Directory is used for on-premises authentication. It can also be used for online
authentication too if Office 365 is configured for identity federation (more later). CRM will
create some specific Active Directory security groups. The domain in which CRM runs must be
in one of the following AD Mode: - Windows Server 2003 Native, Windows Server 2003 Interim,
All Windows Server 2008 and 2012 modes.
ADFS – To access an on-premises CRM over the internet an IFD (Internet Facing Deployment)
must be created which uses claims based authentication such as Active Directory Federated
Services v2.0.
SharePoint – 2010 with SP1 or 2013 can be used as a document repository for CRM. A CRM List
View component (either 2010 or 2013 version) must be installed on SharePoint.
Exchange – Can be used for synchronization of mails, tasks and calendar items using either the
CRM Email Router, Server-Side Synchronisation or the CRM Client for Outlook.
Language Packs – Installed separately and apply to the CRM user interface and help.
CRM ITSELF
The CRM server itself is the engine that controls access to data, makes the user interface available and
runs workflow processes and the synchronization jobs which pull changes from Outlook’s offline CRM
database (if used).
You can access CRM with IE8.0 or higher Firefox and Chrome on Windows Vista or higher and Apple
Safari on Mac OS-x 10.7 or higher. If an unsupported browser is used then CRM will show the Mobile
Express forms interface (the same forms you see if you add /m to a CRM URL).
Tablet applications are available for Windows Surface and iPad.
A number of front and back end server roles perform these tasks and they can all be installed on the
same machine or on separate machines to achieve performance and scaling benefits.
FRONT END ROLES


Web Application Server – The CRM web interface - access to data through the web and
Outlook. Includes the Unzip service for importing data to CRM. The default port for the CRM
website is 5555. If you are going to use ADFS on the same machine this MUST use the default IIS
website so in this case you must install CRM somewhere other than the default website.
Organisation Web Service – Enables the execution of the methods from the Software
Development Kit (SDK) e.g. web service calls in to CRM for data access and manipulation.


Discovery Web Service – Enables the web service that lets a user discover the CRM
organisations to which he/she has access.
Help Server – Powers the CRM Help
BACK END ROLES



Asynchronrous Processing Service – Powers async operations such as bulk email, workflows,
async plug-ins and imports.
Email Integration Service – Sends and received emails by communication with the external
email server.
Sandbox Processing – Provides an isolated environment for plug-ins and custom code to
execute within.
DEPLOYMENT ADMIN ROLES



Deployment Tools – Deployment Manager (Microsoft Management Console tool) for managing
CRM deployments and Windows PowerShell cmdlets.
Deployment Web Service – Web service for creating and managing CRM deployments from
code using the methods outlined in the SDK.
VSS Writer Service – Volume Shadow Copy Service for backing up and restoring CRM data.
OUTLOOK
CRM for Outlook is available in 32 and 64 bit versions and is tightly integrated with Outlook to present
CRM forms. It has an offline capability which is either configured at install or the first time the user
presses the “Go Offline” button.
The offline mode uses a local version of the CRM platform logic, a local web server and SQL Server
Express to store and work with data locally and then resync that back to the CRM server when a
connection is re-established.
The “Go Offline” privilege is a CRM security setting so we can turn it off for certain users.
SSRS
The CRM Reporting Extensions that are installed to SSRS to enable reporting for CRM deploy (more
about these in Chapter 3): 


CRM Fetch Data Processing Extensions – for running Fetch-based reports.
SQL Data Processing Extensions – for user authentication, to allow SQL Reports to be run when
SSRS is on a different machine to CRM.
Default Reports – the out of the box reports for CRM.
CHAPTER 2: INSTALLING CRM
The minimum and recommended Hardware requirement for CRM for a full server installation are: -
CRM is installed only on Windows Server 2008 SP2 minimum, 2008 R2 SP1 minimum and 2012 64 bit
machines. It can work under server virtualization.
For SQL Server, 4GB minimum is required and 16GB recommended and the versions are SQL Server 2008
minimum SP3, SQL Server 2008 R2 minimum SP2 and SQL Server 2012 minimum SP1. All 64 bit. It is
recommended to put SQL on a different machine to CRM for performance but the two machines must
be in the same domain. CRM uses Windows Authentication only to connect to SQL Server. Microsoft
recommend that both machines be on the same LAN.
The account that SQL Server uses to log on to the network must either be a domain user account or the
Network Services account. CRM is going to create the MSCRM_CONFIG central configuration database
and one database per each organization that is configured. Note that this means only ONE deployment
of CRM is supported per database instance in SQL Server.
At installation CRM installs to: \Program Files\Microsoft Dynamics CRM\
Under here you will find the source code, the web site, the unzip folder for exploding solution files,
language files and the RDL (report definition language) files that define the reports. Install also creates
two IIS App Pools (one for running the web application and one for the deployment service).
The Active Directory group configuration is often problematic at CRM install, depending on your
permissions so here are the four groups and their purpose explained in full: -
All Group Names have a GUID appended at installation. If an installation fails then MSFT recommend
that you remove these groups before doing further installs to keep things tidy.
The course notes include a long list of other elements that get installed if they are not already present
on the target machine such as .Net Framework 4.0, Chart Control for .Net, PowerShell, Windows Identity
Foundation etc.
WEBSITE
You can specify the website port at install or leave it blank so that the default 5555 is used. As already
noted, if you are going to put ADFS on the same machine that MUST be on the default website so in this
case you need to install the CRM website somewhere other than default.
Although IIS supports multiple bindings for the same website (e.g. HTTP and HTTPS), CRM does NOT
support this and you must chose only one – in the Deployment Manager this is a radio button. You can’t
create a HTTPS website direct from the installation and so MSFT recommends that you create the site in
IIS first and then run the install and reference it. You can change bindings AFTER install too of course, by
updating IIS and CRM Deployment Manager.
A similar rule applies with Host Headers; if you want to create a host header to allow users to access
CRM with a short friendly URL pointing to the default http://computername:5555 then MSFT
recommends you set up the website, host header and DNS entries before you install CRM.
Users should also add the CRM URL to the appropriate security zone in Internet Explorer to remove the
user name and password challenge.
INSTALL RIGHTS
Installing user does NOT have to be a domain administrator but they do need: 1) Ability to create security groups within the target Organisation Unit (OU) in Active Directory.
2) SQL Server admin privilege.
3) Local Admin rights on the machine where CRM is being installed.
If the user does not have 1) then the groups can be set up before hand by a user with that permission
and CRM tasked to use these groups – this option is only available with the command line set up of
CRM.
INSTALL CONFIGURATIONS
You can install everything on to one server although this is not the recommended production scenario of
course from a performance and disaster recovery point of view. This single server also cannot be the AD
Domain Controller.
For scaling multiple servers can be used including one for SQL Server, one for CRM front end services,
one for back-end services etc.
To troubleshoot an installation you can look at the default log location under
AppData\Roaming\Microsoft\MSCRM\Logs
The course listed a number of common installation troubleshooting tips such as checking firewall
settings for the specified port of the CRM website, checking that the firewall is configured for the port
on which SQL Server communicates (1433) and running dsa.msc to inspect the AD users and
organizational unit.
Post-install tasks include deploying CRM Reporting Extensions, extra language packs, configuring CRM
for IFD and setting up the email sync method (if required).
COMMAND LINE INSTALL
A command line install of CRM is possible and this has the advantage of being an unattended install. It is
launched with the following command line option. If you do not specify parameters then the normal
install interface windows are shown…
The /Q denotes Quiet mode and ensures no pop ups or dialog windows are shown during install. To use
this mode you must create an XML file of the install configuration data. The implementation guide
provides a detailed description of the XML structure and elements. It is in this file that you place the
name of any pre-crated AD groups e.g. the scenario where the person installing CRM does not have
permission to create groups and so this has already been done for them.
CRM ONLINE
CRM online is a different beast of course, in which the installation and deployment is done by Microsoft
and you have no access to any of the “back-end” elements. The one thing left to manage is the
ADMINISTRATIVE ROLES responsible for subscriptions and licenses and this is done through a number of
administrative roles on Office 365: 




Billing Administrator
Global Administrator
Password Administrator
Service Administrator
User Management Administrator
Note that these are not the same as the Security Roles within CRM itself, these are admin permission
for managing the online service instance.
Admin roles are assigned to users through the O365 portal, this is completely optional – without such a
role the user will “just” be a user of CRM.
The O365 portal is also the place where you can see your storage use and judge whether you are getting
close to the default 5GB limit.
CHAPTER 3: REPORTING EXTENSIONS
Dynamics CRM uses SSRS to deliver it reports. All files are defined in Report Definition Language (RDL)
files conforming either to RDL 2008 schema (for SQL Server 2008) or RDL 2010 (for SQL 2008 R2 and
2012).
Reports can use either SQL or Fetch-based queries.
Several default reports are provided with CRM “out of the box” and these are all SQL-based – they
execute SQL against the filtered views in SQL Server to ensure that the security model is applied “at
source”.
Deploying custom SQL-based reports to CRM online is NOT ALLOWED as it represents a heightened
security risk of running malicious SQL against the database. They are allowed for on-premises installs
and give better performance than Fetch queries.
Fetch-based reports using CRM’s proprietary FetchXML language to define their queries.
So what do the reporting extensions actually do?



It supports Fetch-based reports and removes the need to configure trust between CRM and
SSRS.
It is not strictly needed for CRM to run but without it you will have limited reporting options.
It is required if you want to create or import an organization
It does this by installing two things: 1) The CRM Fetch Data Processing Extension to support Fetch based reports.
2) SQL Data Processing Extension to schedule SQL reports and to enable custom reports to run
when SQL Server and CRM are not on the same machine and trust delegation is not configured.
So essentially, Reporting Extensions makes the security work and enables the CRM-specific Fetch syntax
for reports. Without it’s we’d need to set up the Kerberos “double-hop” authentication in which a
user’s authentication is maintained over multiple connections.
This means, quirkily, that if you write custom SQL-based reports for CRM on-premises they will work even
if Reporting Extensions is not installed – as they do not rely on FetchXML.
Don’t forget that Reporting Extensions is installed AFTER CRM as a post-install operation. In fact the
windows dialog interface will prompt you to do this if the URL of SSRS was given.
For better performance, SQL Server and the Reporting Extensions can be deployed to a different server
than CRM. Even if they start off on the same server they can always be moved later.
It is recommended that the account used to run SSRS is not used to run any CRM components, for
security reasons.
REPORT AUTHORING EXTENSIONS
In addition to the SSRS Extensions there is also a Reporting Authoring Extension which can be installed
on the computer where SQL Server Business Intelligence Development Studio or the SQL Server Data
Tools are installed.
Its purpose is to obtain the data from CRM and use it to validate FetchXML queries used in reports. It is
only available as a 32 bit version however.
CHAPTER 4: DEPLOYMENT MANAGER
Deployment manager is the tool used to redeploy CRM and to perform administration tasks such as
creating new organisations, importing organisations, managing servers etc. Windows PowerShell can be
used for the same tasks.
The Deployment Manager software is available on machines that have the Deployment Tools role
installed.
Deployment Manager is actually is Microsoft Management Console (MMC) snap-in. It can be used to
manage multiple machines if the CRM roles have been spread across multiple computers for
performance benefits but it manages one DEPLOYMENT only (e.g. one MSCRM_CONFIG database).
To execute the Deployment Administrator you must have this role. It is automatically given to the user
that performed the CRM install. This is not a CRM role, it is managed in the Deployment Manager and
is, I believe, a role in Windows security.
Via Deployment Manager you can: 1) Add/Remove Deployment Managers
2) Create new organisations/view and change the properties of existing ones/delete an
organisation
3) Enable/disable organisations – you need to typically disable before you can make configuration
changes.
4) Import an organization by attaching to a CRM database instance and perform the mapping of
users to transfer the GUIDs of the previous Active Directory accounts to the new CRM instance
accounts.
5) Allow updates to install (depending on the type of update).
6) Manager the servers that comprise the CRM solution including disabling a server (although you
cannot disable the SQL Server and Reporting Extensions Server via Deployment Manager)
7) Delete a server – you will need to rerun the CRM install and setup any roles on the deleted
server if you ever need to undelete it.
8) Configure a CRM instance to be an Internet Facing Deployment (IFD).
9) View the CAL licenses assigned and their types.
Note that CRM install sets up the web application server, the organization web service, discovery web
service and deployment web service. If you want to change the address or bindings of these after install
you must first do so in IIS and then come to Deployment Manager and make the change. Changing
deployment manager does NOT update IIS. If SSL or load balancing is used then there are options for
these two under “Properties” in Deployment Manager.
POWERSHELL
CRM cmdlets are installed on the machine which has the Deyploment Tools role. They allow you to
issue command line instructions to retrieve and change CRM deployment settings and are an alternative
to the Deployment Manager interface.
Before they can be used you must register the commands with the following instruction in a PowerShell
window: Add-PSSnapin Microsoft.Crm,PowerShell
To list all commands use: Get-Help *crm”
You can do many powerful things with the command line and of course it has the great advantage that it
can be scripted. Here is an example of changing an organization name.
CHAPTER 5: UPGRADE TO CRM 2013
Only CRM 2011 with Update Rollup 6 or 14 (or later) can be upgraded to CRM 2013. Earlier versions
must follow a full upgrade path e.g. Version 3.0 to 4.0 to 2011 to CRM 2013!
CRM 2011 server roles are not compatible with CRM 2013 so if you are doing an “in-place” upgrade of a
CRM 2011 machine with multiple servers then once the first one has been moved to be a CRM 2013
server, all the other CRM 20011 instances will stop working and must also be moved.
When multiple servers are involved they can be upgraded in any order.
MSFT has the following terminology for upgrades: 


In-Place – an existing CRM 2011 server is upgraded to CRM 2013
Migrate with Same SQL Instance – a new CRM 2013 server is provisioned but is pointed to the
existing CRM 2011 back-end database which it will upgrade
Migrate with New SQL Instance – a new CRM 2013 server is provisioned and pointed at a new
database server in which the CRM 2011 is restored
Each approach has its pros and cons in terms of the extra hardware needed, the fall back plan in case of
upgrade failure and the downtime needed.
Of course if you need CRM 2011 and CRM 2013 databases to continue to live side by side in the same
SQL Server then you will need separate named instances as each will need the configuration database
MSCRM_CONFIG.
The CRM Connector for SQL Server Reporting Services must be uninstalled before an upgrade is
attempted.
The user who runs the upgrade needs some particularly elevated rights: 1)
2)
3)
4)
Must have an account in the AD domain of the server(s) being upgraded.
Must have the Deployment Administrator role and be a CRM System Administrator.
Must have admin rights to SQL Server.
Must be able to create the new security groups in the AD OU. Unlike a clean install it seems that
we can’t ask someone else to do this and simply connect to the groups at installation time.
A legacy feature tool and a CRM 2011 Custom Code inspection tool are available to check and validate
an instance prior to upgrade to CRM 2013.
TABLE MERGE
One big aspect of upgrading from CRM 2011 to CRM 2013 is that 2011 used to have two tables per
entity – a base table with all the system fields and an extension table with the custom fields. This
caused performance issues and so CRM 2013 uses just a base table.
As a result, table data must be merged to move from the CRM 2011 to 2013 schema and since this is a
time-consuming operation the upgrade path allows you to DEFER it to a later date and time e.g. CRM
2013 will function (but with some features deprecated) using the CRM 2011 schema.
Only an IN-PLACE upgrade can benefit from this deferral, if you are migrating using the same instance
of SQL Server then you can’t avoid the table merge running.
MSFT recommends however that you perform the table merge either at the time of upgrade or very
shortly thereafter.
The defer of the table is done by: 1)
Setting a registry key to ensure that the merge does not happen at time of upgrade!
2) Restting this key back when you are ready.
3) Set another key to allow custom indexes to be recreated after table merge as these are dropped
during the merge process for a speed enhancement.
4) Disable the CRM organization.
5) Run the table merge tool which is found in the CRM source code folder under Tools folder. It is
a console application run from the command prompt.
6) Re-enable the organization.
You can run the merge for a sub-set of entities only to spread the work over multiple sessions –
particularly useful if you have a large database for which the merge is very slow.
The user that runs the merge must have dbowner permissions on the SQL database being merged, be in
the Deployment Admin group and have Admin rights on the machine where SQL is installed.
UPGRADE PROCESS
To upgrade MSFT recommends the following steps: 1)
2)
3)
4)
Prepare to Upgrade
Establish a Test Environment
Update and Validate Test Environment
Update and Validate Production Environment
PREPARE: Decide what upgrade strategy to use, create a rollback plan to ensure minimal disruption to
business if the upgrade fails. It should include an upgrade checklist and provision for UAT for full
confidence in the migrated system.
ESTABLISH TEST ENVIRONMENT: Microsoft recommend that you establish a test environment and
upgrade that first before attempting the work against a production system. The test environment can
become the new production depending on your needs. At least one migration should be performed
here. Microsoft also recommend a new test domain that has trust settings to the production server.
Note that is you ever backup and restore MSCRM_CONFIG you will need to update some settings at it
will contain references back to the original instances of each CRM organization.
UPGRADE AND VALIDATE THE TEST: The upgrade is actually run in the test environment and results
scrutinized with the checklists and user acceptance testing.
UPGRADE AND VALIDATE THE PRODUCTION: Perform a full backup of the CRM 2011 databases prior to
beginning, perform the upgrade and validate. For a full backup Microsoft recommends that 3 times the
SQL Server database file is available in space and 4 times the SQL Server log file!
EMAIL ROUTER & OUTLOOK
The Email Router can be upgraded to preserve configuration settings such as the incoming and outgoing
profiles.
5 configuration and XML files must be backed up before attempting an upgrade.
The Outlook 2013 client is not compatible with CRM 2011 so the server should be upgraded before the
Outlook clients. The configuration settings used for CRM 2011 Outlook are brought across to CRM 2013
including things like server name. These may need to be updated in each client by rerunning the
configuration tool. The base language cannot change in a CRM for Outlook upgrade.
You cannot upgrade CRM for Outlook when it is in Offline mode.
If you wish to take the opportunity to move from 32 to 64 bit Outlook during the upgrade than a
complete reinstall of Outlook is necessary.
There is more about the email router in the next chapter.
CHAPTER 6: EMAIL MANAGEMENT
CRM does not include email processing functionality but it does integrate with: 1) MS Outlook to interact with email via the client’s email box.
2) Server-side synchronization to link CRM with Exchange.
3) Email-router for server-side integration between CRM and an email server.
If server-side email synchronization is used then the deployment administrator must choose 2) or 3) –
you cannot mix both.
You can however have some users using Outlook and others on the server-side mechanism,
The Email Router is a separate program, installed separately and then configured to act as the bridge
between CRM and email server. It supports Exchange 2007 and is easier to use for large deployments
since it is centrally managed. Appointments, Contacts and Tasks must still be synchronized with Outlook
however as it only deals with email.
The server synchronization works only when CRM and Exchange are both on-premises or both online
and is also centrally managed. It does synchronise Appointments, Contacts and Tasks as well as email.
It does not support Exchange 2007 however. It also enables alerts within CRM for problems.
Outlook required minimal configuration but the synchronization only works if Outlook client is running
and it does not work with queues.
The email settings are found in CRM under Settings > Email Configuration
With one of the three sorts of email synchronization turned on, incoming emails are tracked as Activities
in the appropriate records history. They are set up as closed activities. Users can choose in their Set
Personal Options > Email tab whether they want: 



All emails tracked
Only those that were received in response to a CRM email
Emails from leads, contacts or accounts or
Emails from ANY record that is email enabled (e.g. has an email address)
The second one is the default.
How do the tools decide what CRM record to log incoming emails against? There are three methods: SMART MATCHING: CRM looks at the subject line and the list of recipients and uses that to work out
what it believes is the existing thread, within the CRM, for that email. It ignored the “Re” in the subject
line.
TRACKING TOKEN: CRM appends a code in the format CRM:nnnnnn to the email subject and uses that in
any replies to know where to store the email in CRM.
EMAIL HEADER: New to CRM 2013 is the ability to code tracking information in the email header. This is
not available with the email router however. Because headers can be changed and ignored, MSFT
recommends not relying on this method alone but combining it with either of the previous two.
FORWARD MAILBOX
In a large organization, listening to hundreds of user’s mailboxes to detect the useful traffic is a serious
overhead. Microsoft have therefore devised the concept of a “forward mailbox” in which each user’s
mail is forwarded to a single central “forward” mailbox as an attachment and the CRM email monitoring
only has to listen to this ONE location.
The sequence of events is: 1)
2)
3)
4)
Email received in user’s mailbox or on a queue.
Forwarding rules sent it on to the forward mailbox as an attachment.
The Email Router or Server Sync sends them to CRM.
CRM decides whether to create a record and if so where.
5) Optionally the forward mailbox is tidied up by deleting processed records.
The rules at step 2 can be created using the Rule deployment Wizard which is included with the Email
Router download.
MAILBOX RECORD
CRM 2013 introduces the mailbox record – the central place where a user’s email settings are
configured. Mailboxes are created for all users and queues and you must manually create a record if
you wish to use a forward mailbox.
Separate methods for handling incoming and outgoing emails can be set as can the credentials if using
server synchronization. The available INCOMING methods are: 



None – no email tracking occurs and the only possibility is manual tracking from Outlook.
Outlook – Outlook will automatically decide to track some emails based on the tracking rules.
This option is not available for queues.
Server Sync or Email Router – the emails for this user are being handled with server-sync.
Forward Mailbox – the emails are being forwarded to a forward mailbox and processed there.
Microsoft stress that a forward mailbox should be used as soon as you have a significant number of
users.
The OUTGOING methods are: 


None – no email dispatch occurs for users or queues with this setting.
Outlook – Outlook will be used to send emails for users with this setting, they must have the
Outlook CRM client installed.
Server Sync or Email Router –emails are delivered with one of the server-side methods.
The recommended method is the sever-sync/email router.
Default methods for incoming and outgoing can be set so that they are applied to all new users and
queue’s mailboxes. There is also an option in CRM to re-apply the default settings to one or more
mailboxes to make a bulk change.
CRM contains an approval logic for new or changed email addresses. This only applies to users who use
server-based methods and to all queues. There is a special “Approve Email” security privilege to control
who performs approval.
CRM can then be set to process emails only for approved users and queues under Administration >
System Settings > Email.
EMAIL ROUTER
The router is a Windows service that routes emails between CRM and an email server. It also includes a
configuration manager and the rules deployment wizard. It is available in 32 bit and 64 bit editions.
The email router can work with: 


Exchange 2007, 2010, 2013, Online
SMTP
POP3
You can also develop your own custom providers. 1GB minimum and 2GB recommended RAM is
needed for the email router with 100MB of space.
The email router must be configured to use at least one email server profile. These are configured
within the CRM under Email Settings and allow you to set the protocol, authentication type etc. The
screenshot gives an example for Exchange Online.
If you are authenticating to the email server with clear text then MSFT recommends that you enable
Secure Socket Layer (SSL).
Depending on the email server type, the server location will be specified either as a URL or computer
name: -
Email router can either use a local system account, an administrator’s credentials or the credentials of
each individual user to monitor the email server. Local System Account is only available for Exchange
and only works if there is a trust relationship between the email server and the computer where the
router is running
The email router must be pointed at the appropriate CRM deployment, specifically the discovery web
service and the access credentials provided. Email router can process emails for multiple CRM
deployments but they must all be of the same type.
The forward mailboxes used by email router work by having each individual user’s mailbox send a copy
of all emails to the forward mailbox as attachments. We configure these rules using the Rule
Deployment Wizard. It can only be run against Exchange servers, not POP 3.
For POP3 you could create a “normal” mailbox via Outlook for example.
SERVER SIDE SYNCHRONISATION
Provides the same functionality as the email router but is built in to CRM and requires no separate
installation. It is available for both on-premises and online (since the Spring 14 update) CRM and a list of
the supported server types can be found here: http://technet.microsoft.com/en-us/library/dn531050.aspx
It can work with Exchange or POP 3/SMTP protocols.
The big advantage of server sync is that it also synchronises contacts, tasks and appointments with
Exchange and provides alerting on issues via the CRM alert entity. It introduces performance counters
too for diagnostics and monitoring.
There is an option within CRM to help migrate Email Router settings to Server-Sync.
To set up server-side sync we need to: 1)
2)
3)
4)
Enable the synchronization under Email Configuration Settings in CRM
Configure user and queue mailbox records
Configure forward mailboxes if required
Configure at least one server profile in CRM
In terms of authentication between CRM and the email server the option are: -




Specify the credentials for each user or queue’s mailbox record in CRM. CRM must be using SSL
for this.
Specify one set of credentials for the whole email server. CRM must be using SSL for this.
Use Windows Integrated Authentication in which case the credentials of the CRM Async Service
are used to work with the email server
Anonymous is used if not authentication is required
Note that since the Spring 14 CRM update, if the Exchange Online service is also purchased then a Server
to Server protocol connection between Exchange and CRM is automatically set up.
Note that, as stated in the first tow bullet points above, CRM must be using Secure Socket Layer (SSL) if
you want to store and pass credentials for email server authentication. If you’re working with onpremises however you can disable this (for testing ONLY!) by running a PowerShell command.
One top tip is that it is the Async Service which processes server-side email sync. This service also
handles workflows and so if you find you have a performance problem it is possible to install the Email
Integration Service role on a dedicated server instead. This will install a second copy of the Async
Service which ONLY handles mailboxes.
Remember there is the “Test & Enable Mailbox” option throughout CRM to check that everything is set
up as expected.
Finally, the synchronization of Tasks, Appointment and Contacts by the server-side sync is controlled
separately from email so it can be enabled/disabled independent of email configuration.
CHAPTER 7: DYNAMICS CRM FOR OUTLOOK
Stability for the Outlook client has improved as it now uses multiple processes to do its work rather than
performing all activities in the main Outlook process. The Outlook client for CRM 2011 can be used with
CRM 2013 as long as it has Update Rollup 12 installed – this might help with transitioning between 2011
and 2013 but the offline feature can’t be used until you upgrade to the proper 2013 version.
SQL Server 2008 Express is used to power offline functionality.
2GB minimum and 4GB recommended are needed for CRM for Outlook.
It is supported on Office 2007, 2010 and 2013 running on Windows Vista, 7, 8, 2005, 2008 R2 and 2012.
IE8 or 9 or higher must be present.
There are four ways to deploy it: 

Manual – A user with Local Admin rights on the target computer runs the install.
Download Link – on visiting the CRM web application, a user without the client will be
prompted to download and install it.


Group Policy – a Group Policy (a feature of Active Directory) can be used to roll the software out
to a large number of individuals.
Microsoft System Centre Configuration Manager – use this aspect of Microsoft System Centre
to roll out the software to a large number of users
After install, CRM for Outlook must be configured, on which you point it at the CRM URL and test the
connection.
A command line install of Dynamics CRM for Outlook is also available and uses an XML configuration file.
You can connect to MULTIPLE CRM instances but only one of them can be the SYNCHRONISATION
instance. You can only go offline and track items with the synchronization organization.
OFFLINE
A user-configurable sub-set of CRM data is loaded in to a SQL Server 2008 Express database stored
locally and then all changes made to it and recorded in a “playback graph” – a queue which is reexecuted against the CRM server when connectivity is re-established. The maximum size of the offline
database is 10GB.
A user goes offline automatically if connectivity is lost or can manually opt to “go offline”. Data is
downloaded at the time that the “go offline” button is pressed. If you manually went “offline” then you
need to explicitly hit the button to return back “online”.
The frequency with which data is pulled down to the SQL Express database is configured in Outlook
settings and the minimum is 15 minutes.
The execution of the playback graph is intelligent – if a user’s rights or a record’s state has changed since
the user went offline then certain changes may be ignored.
If two users go offline and change the same record then when they go back online it is the last one that
wins e.g. whoever plays back their graph last.
Two types of filters can be created for the data to be taken offline – system filters that are set up by the
administrator and cannot be overwritten by a user and user-specific filters so that a user could choose,
for instance, to just take data they own offline. Filters are set up with an interface similar to the CRM
Advanced Find window.
CHAPTER 8: INTERNET FACING DEPLOYMENT (IFD)
An on-premises or partner-hosted CRM that we wish to expose over the internet is known as an
“Internet Facing Deployment” (IFD). It must use claims-based authentication such as Active Directory
Federated Services (ADFS). It gives the benefit of a single-sign-on experience and is required for some
applications like CRM for tablets.
This is a particularly difficult chapter that relies on a knowledge of security certificates, trust
relationships and ADFS security. Some good walkthroughs with screenshots can be found here: -
http://blogs.msdn.com/b/niran_belliappa/archive/2014/01/16/step-by-step-configuring-crm-2013internet-facing-deployment-ifd.aspx
http://msdn.microsoft.com/en-us/library/gg188602.aspx
So what is claims based authentication? The principle is that the user requesting access gets a secure
token from an approved provider (called a Secure Token Service) such as ADFS and uses this to present
several pieces of information about themselves (the claims). The application validates the security
token, examines the claims and decides whether to grant access. ADFS is only one STS, any provider
that implements the STS protocol could perform this role but for the purposes of CRM, ADFS is the one
that is used.
Some more information here: - http://msdn.microsoft.com/en-us/library/gg334502.aspx
The course notes provide a more detailed view of the communication steps involved: -
For this communication to work: 1) The STS must be configured to issue correct tokens for users.
2) The STS must be configured with details of the application (CRM).
3) The application must be configured to trust the STS identity provider.
CONFIGURIING ADFS & CRM
The key elements of configuring are: 






The CRM Server must have access to the STS. STS must use the Web Services trust model (WSTrust) 1.3 standard. ADFS Version 2.0, 2.1 and 2.2 are supported.
The CRM website must be configured in IIS and Deployment Manager to use HTTPS binding.
This can be on the ONLY binding… even if IIS allows multiple binding, you’ll see that the binding
in Deployment Manager is a radio button to select EITHER http OR https and NOT both!
Certificates are therefore required for HTTPS, in fact we need 3 certificates for ADFS and 1 for
CRM. Certificates always have an expiry date and so should be renewed regularly. ADFS
certificates are renewed automatically.
The account used by the CRMAppPool of the CRM web application needs read permission to the
private key of the certificate used.
ADFS must be exposed on the default web site. So if you’re using ADFS and CRM on the same
machine, CRM cannot be on the default web site.
Similarly, ADFS and CRM must use different port numbers if they are on the same machine.
MSFT recommends that you stick with default port 443 for CRM (to avoid users having to type
it) and put ADFS on a different port such as 444.
DNS records must be set up on the server that hosts the record for the external domain that the
IFD is exposed on. Records are needed for the ADFS Server, for each CRM organization, for the
CRM discovery web service and web application server role.. The IFD configuration wizard can
be used to set some of these up.
NOTE THAT: Windows Server 2008 and 2008 R2 include ADFS v1.0 which is not supported for CRM so
ADFS 2.0 (minimum) must be downloaded and installed. Windows Server 2012 and 2012 R2 include
ADFS 2.1 and 2.2 respectively so they are fine!
Once ADFS is installed you must launch ADFS having already prepared a certificate with specifies an
external name for ADFS. You then configure ADFS by: a)
b)
c)
d)
create a new stand-alone federated server
configure a claims rule for Active Directory
go and configure claims-based authentication for CRM (see the paragraph below)
set up a relying party trust for each type of access that will be used to get to CRM e.g. internal
AND external/internet access.
e) set up claims rules for the relying party trust so that ADFS will accept incoming requests from
CRM (3 rules are needed: pass-through UPN, pass-through SID and Windows Account name to
name)
At step c) you go and launch the Configure Claims-Based Authentication Wizard from CRM Deployment
Manager and supply the URL end-point of the STS service and select the certificate used for
communication between CRM and STS. This certificate must be installed on the servers running the web
application, discovery and organization web service roles.
Claims-based authentication is also disabled via the Deployment Manager.
Note that claims-based authentication can also be enabled via PowerShell commands for a silent install.
Once ADFS has been set-up as described above you can launch the Configure IFD Wizard from
Deployment Manager where you provide the domain names of the web application and 2 web service
end points and the external domain.
IFD is also disabled via the Deployment Manager.
Note that IFD can also be enabled via PowerShell commands for a silent install.
Finally we add relying party trust to ADFS for CRM IFD.
CHAPTER 9: MAINTAIN A DEPLOYMENT
At CRM installation you set up the accounts to be used for all the different services (async, unzip,
sandbox, VSS etc.) These account details are used as specified in the following table: -
So, for example, whatever you specify as the account for the Application Service is set as the credentials
for the CRMAppPool in IIS.
You can use the Network Service account for these services but MSFT recommend that you use a
dedicated low-privilege account to secure your CRM. Whatever account is used it must be a member of
the Domain Users group. The account used for Async and Sandbox must also be a member of the
Performance Log Users group.
If you ever need to change these accounts you need to rerun the CRM installation code and select
“Repair”.
Note that there are two CRM async jobs running – one that handles routine tasks such as data import,
workflow execution, bulk delete and the other which is performing database maintenance activities.
If you need to review system jobs then you can do so from within the CRM via the Settings > System
Jobs screen. The course notes detailed a long list of the specific jobs that might be running (language
pack update, mailbox test access, index management etc.)
If you find that the async process is overwhelmed by the number of jobs you can use a PowerShell setting
to limit the number of async jobs that can be queued.
If you need to remove a large number of queued jobs then (as with any other record) you can use the
Bulk Delete functionality in CRM to set up the Delete Criteria in an interface similar to Advanced Find.
DISASTER RECOVERY
A sensible disaster recovery strategy for CRM is : 1)
2)
3)
4)
Regular back ups of the MSCRM_CONFIG, organization and ReportServer databases.
Regular back ups also of the master and msdb databases.
Backup of the XML configuration files used by Email Router.
Back up of the system state of domain controllers. MSFT recommends that at least 2 domain
controllers are installed so that total loss of AD is very unlikely.
5) A back up of the SharePoint databases, if SharePoint is used.
6) A copy of any 3rd party managed/unmanaged solutions that have been applied to CRM.
Disaster recovery will probably involve provisioning a new machine, joining it to the domain, reinstalling
the necessary software, restoring databases (the order should be master, msdb, MSCR_CONFIG and
then organisations) and using Deployment Manager to join to an existing database.
DATABASE
Microsoft recommends using a Redundant Array of Inexpensive Disks (RAIS) for storage of the database
files. Ideally the SQL Server programs files, the database file and the log file should be on different
physical disks to improve input output speeds (I/O) and performance.
CRM still lacks proper archiving functionality so MSFT recommends that you use the Disk Usage by Top
Tables standard report in SQL Server to monitor table size and archive records to Excel (!) periodically.
Additional database tricks you can try for performance or storage enhancements are: 1) Row Compression – enable table for row compression for enhanced storage of variable-length
numeric types.
2) Page Compression – store common values only once and reference them whenever they are
used elsewhere. If page compression is enabled, row compression is enabled by default. This
will hurt performance but save on space so should only be used on tables that do not change
often.
3) Sparse Columns – columns with lots of null values can have this enabled to save on space but at
the expense of a performance loss for accessing non-null values. Never set a nonsparse/densely populated column as sparse as the storage need will go up significantly.
4) Indexes – adding indexes direct to SQL Server is supported for CRM. A DBA should do this after
careful consideration of the index benefits and making use of the index analysis tools within SQL
Server.
TROUBLE SHOOTING
Where can you go to get information if things are not behaving as expected?
1) Windows Event Log – CRM writes entries to the Windows Application log in Event Viewer. Filter
the messages here and see what it has been up to! Only the events relating to the roles that are
installed will write messages of course. You can create a custom view to give you quicker access
to the events of interest.
2) Performance Counters – CRM adds many performance counters for you to monitor the system
health.
3) Diagostic Web Page – CRM includes a diagnostic web page of the key performance metrics you
will find it at: http://[ORGANISATIONNAME]/tools/diagnostics/diag.aspx
A screenshot is provided – this diagnostic page can be run for both on-premises and online instances of
CRM.
4) Tracing CRM – tracing must be explicitly turned on for CRM. This can be done either by
changing a Registry Key (turns on tracing for one server only) or by using a Power Shell
command (turns on tracing for all servers in a deployment). Trace files are written to Program
Files\Microsoft Dynamics CRM\Traces The registry key of interest is: HKEY_LOCAL_MACHINE\Software\Microsoft\MSCRM
5) Tracing CRM Outlook – tracing for the Outlook client can also be enabled via registry key change
or via the diagnostic tool which is run from Microsoft Dynamics CRM > Diagnostics in start menu
or search on Windows 8. The registry key for Outllok tracing is given after the screenshot: -
HKEY_CURRENT_USER\Software\Microsoft\MSCRMClient
Of course all points mentioned here about tracing and changing registry keys, apart from the diagnostic
web page apply only to CRM on-premises where you have control over such elements.
6) Best Practice Analyser - There is a Dynamics CRM Best Practice Analyser (BPA) which can be
installed separately and gives advice on CRM configuration and potentioal issues. It relies on
the Microsoft Baseline Configuration Analysr 2.0 software (which must be installed as 64 bit).
It will highlight any areas where you are non-compliant with best practice.
UPDATING MICROSOFT CRM
MSFT periodically releases update roll-ups for CRM and each of its linked elements (Outlook, Reporting
Estensions, Email Router, Reporting Authoring, Language Pack). These roll ups contain cumulative fixes
and do NOT introduce new features. Update roll ups are cumulative, they should include all previous
fixes but they can have dependencies on earlier roll ups. Often MSFT recommends that you make a
system back-up before applying a rollup. A Knowledge Base article appears for each roll-up with more
details.
In between update roil ups, hot fixes may be released for urgent problems but these are not pushed out
publically and you must obtain them and install them yourself.
Microsoft Update can be used to auto download and install updated for CRM and you are prompted for
this option at CRM installation. Even if you do not select this at installation you can go to Windows
Update and change the setting later. Without automated update you are obliged to download the
update yourself and install it manually.
There is also the Windows Server Update Service (WSUS) can also be used to apply updates.
For multi-server deployments, the same update must be applied across all machines. It is not supported
to run multiple machines on different update versions.
An exception to this is Outlook, it is allowed to be one version behind the CRM server!
You can look in Control Panel > Prorgrams and Features > View Installed Updates to see the CRM
entries or you can look at the properties of the CrmVerServer.dll file in Program Files > Microsoft
Dynamics CRM > Server > Bin to see the file version number.
Some updates can be uninstalled via the usual Windows uninstall route – others however cannot and
you’d need to rebuild the CRM server entirely (!) to get rid of them.
DATA ENCRYPTION
Here’s the essentials of CRM encryption: 1) Standard SQL cell-level encryption is used for password fields in system entities. You can’t apply
this level of encryption to other CRM fields.
2) Each organization has an associated encryption key and you will need this when importing an
organization if it makes use of encrypted fields. The encryption settings are found in the CRM
under Settings > Data Management > Data Encryption. You can only change the encryption key
if your CRM is under HTTPS. MSFT recommend that the encryption key is changed once a year
and that you keep a backup.
3) An allied security setting in CRM controls access to the Data Encryption functionality.
VOLUME SHADOW SERVICE (VSS) WRITER FOR CRM
Added functionality for backup and restore of CRM databases is available through the VSS framework.
This sets up an API interface that allows other system monitoring software such as System Center Data
Protection to perform operations against CRM. It also allows these operations to occur which the
databases are currently in use.
VSS Writer Service can be used with System Center 2012 Data Protection Manager and the SQL Server
VSS Writer service must be started to take advantage of it. At install, a VSS Writer service is created by
CRM for this express purpose.
VSS Writer can work with the MSCRM_CONFIG database and organization databases and it uses a
special XML config file to be able to partially restore MSCRM_CONFIG if its only one organization you’re
interested in e.g. you don’t need to restore the whole thing!
It does not work with SharePoint databases 
CHAPTER 10: HIGH AVAILABILITY
What are the options to configure CRM for high availability? If you are working with CRM Workgroup
edition there are no options (!) as it is confined to a single full-server install. For CRM Server however
we can spread the CRM roles across multiple machines to spread the processing load or place elements
in a load-balancing configuration.
You can install roles across multiple machine to spread the processing load. MSFT recommends that
certain roles are installed together as a group but it is possible to install just a single role on a machine.
Roles are installed by running the CRM install executable and they can be removed through Programs &
Features.
For multiple server set-up MSFT recommends that machines are on the same local area network (LAN)
and that the AD domain controller is on the same LAN to handle the significant amount of traffic that
will pass between them.
Here’s the list of role groups: -
Network Load Balancing (NLB) allows you to install either full or partial CRM roles across multiple
duplicate machines and then have a load balance direct traffic as appropriate. When you set up the
second instance of CRM you should of course connect to an existing database to ensure that the
multiple copies of CRM are all referencing the same, single data store.
SQL Server itself can, of course, be scaled up and out – a SQL Server cluster can be created with a virtual
name which CRM uses to access it. You can modify a registry key to point CRM at a cluster. It is possible
to cluster just the MSCRM_CONFIG database or the ORGANISATION databases as per your needs.
SQL Server log shipping and mirroring are also techniques to maintain extra copies of the SQL Server
ready for fail over. Mirroring is due to be deprecated in future SQL Server versions however and the
“AlwaysOn”* Availability Group strategy is the recommended approach (see next paragraph).
SQL Server 2012 introduces a new approach called “AlwaysOn” Availability Groups. SQL Server must
reside on Windows Server Failover Clustering (WSFC) nodes and it creates an availability group with a
primary database and one to four sets of secondary databases. The secondary databases are read-only
and so can be used for CRM reporting if needs be.
Email Router can also be installed to multiple computers in a cluster for availability and failover
redundancy.
MSFT actively recommend that you have more than one AD Domain controller to provide resilience for
AD failure.
Exchange can also be installed to multiple machines.