Author Archives: tzooki

Dynamics CRM 2015 Unattended Installation using Command Line and XML file

In this new tutorial I will show you how to perform a silent installation for Dynamics CRM 2015. You can use this procedure to quickly deploy Test/Dev and also production enviroments using a pre-configured XML template.Installing CRM with an XML file provides you some features you don’t have in the regular GUI installation such as chosing the names for the Security Groups used by Dynamics CRM.

Example XML Files (Change the doc extension to xml):

With Pre-Configured OU Groups:
https://microsoftdynamicsessentials.files.wordpress.com/2015/04/crmsilentinstallwithpreconfiguredgroups.doc

Without Pre-Configured OU Groups:
https://microsoftdynamicsessentials.files.wordpress.com/2015/04/crmsilentinstall1.doc

Microsoft Dynamics CRM 2015 Update 0.1 Released

Update 0.1 for Microsoft Dynamics CRM 2015 is finally out and you can download it here:

https://www.microsoft.com/en-us/download/details.aspx?id=46552

As you probably noticed Microsoft changed their naming convention and it will no longer be called “Rollup”. The 0.1 update contains many fixes and performance enhancements.

Move AX 2012 to a different Server / Domain

As you probably know Microsoft Dynamics AX 2012 R2/R3 does not have a redeployment utility (like the Dynamics CRM deployment manager) meaning that if you want to move an AX Deployment from one domain to another – you’ll have to get your hands a little dirty.

Some important notes before we start :

  • You can use these steps also in AX 2012 – Just ignore the Modelstore database.
  • You can also use these steps to move a deployment in the same domain – ignore step 4.
  • You need to make sure that the AX installation version in the new server matches the installation
    on the previous server.
  • I’m assuming that you have the basic required knowledge in SQL Server, your Windows Serverenvironments and of course some AX 2012 architecture understanding to do these steps 🙂

Let’s go:

1. Open the SQL management studio and Backup your AX Databases [BusinessData Database + Modelstore Database] for example: AXProd + AXProd_model
2. Stop the AX Service on the new server and restore the databases in the new SQL server – You can restore them with different names just remember that they have to match – for example: AXProdNEW
AXProdNEW_model.
3. In the SQL management studio run the following queries on the BusinessData Database (AXProdNEW):

DELETE FROM SYSSERVERCONFIG
DELETE FROM SYSSERVERCONFIG

— This will delete the AOSID & SERVERID of the previous installation and will
— repopulate the tables with the new server name when the AX service on the new server is started.

Also consider running:

DELETE FROM SRSSERVERS

— This will clear the Reporting Services properties form – you will need to reconfigure this
— later if you want to redeploy the reports.

DELETE FROM BATCHSERVERGROUP
DELETE FROM BATCHSERVERCONFIG

— This will delete the batch server properties of the previous server – You should do this if
— the redeployment is in the same domain because the old server might be reachable by the new one and may use it as a batch server.

DELETE FROM SYSEMAILPARAMETERS

— This will delete the SMTP server parameters for sending emails

4. Now you need to configure your user in the AX Database in the new domain (You can skip this step if you re-deployed AX in the same domain).
Open CMD with “Run as admin” and type:

wmic useraccount where (name='your_windows_username' and domain='your_domain') get name,sid

Example: wmic useraccount where (name='administrator' and domain='contoso') get name,sid

Copy the SID to notepad.

In the SQL management studio run the following query on the BusinessData Database (AXProdNEW):

UPDATE USERINFO
SET SID='your_sid', NETWORKALIAS='your_windows_username', NETWORKDOMAIN='your_domain', NAME='your_full_name'
WHERE ID = 'Admin'

Example:

UPDATE USERINFO
SET SID='S-1-5-21-916693446-2822637979-541647007-1001', NETWORKALIAS='administrator', NETWORKDOMAIN='contoso', NAME='John TheAdmin'
WHERE ID = 'Admin'

— This will replace the AX Admin user to your user – you can modify this query to replace other
— users as well, or you can later add new users from the AX GUI.

5. Grant the AX AOS account permissions over the databases as follows:
AXProdNEW:
db_datareader
db_datawriter
db_ddladmin
public

axpermissions1

AXProdNEW_model:
public

axpermissions2

You can identify the AOS account by going to the services on the application server (start->
services.msc) and check the Log On tab:

axservices1
If you are using NETWORK SERVICES as the service account you will need to grant permissions to the machine$ account – Use the following query to do it:

CREATE LOGIN [Domain\axservername$] FROM WINDOWS

6. All done! Go to services on the application server and start the Microsoft Dynamics AX Service –
it might take a few minutes for it to start. Once it’s running – you can start the application.
If you have any issues starting the service check the server’s event log for clues, and if you have
any questions – feel free to post them here and i will do my best to help you out.

Further optional steps:

1. You should synchronize your Database to make sure everything is working properly.
2. If you want to deploy your reports – you need to fill the Report Servers form and then run the
following command from the Dynamics AX 2012 management Shell:

Publish-AXReport –ReportName *

I hope you find this post helpful! Good luck, Michael.

“The target principal name is incorrect. Cannot generate SSPI context” error message during Dynamics CRM Setup

During Dynamics CRM 2015/2013 setup you might encounter this error in the final system checks process:

11

This is caused due to improper SPN’s (Service Principal Name) configuration for the SQL server. To resolve this follow these steps:
1. Connect to your SQL server and go to services (Start -> services.msc) from there locate your SQL service and check the Log on account

22

2. Open CMD with Run As Administrator and run the following commands one by one (you need to use a high privileged domain account):

setspn –A MSSQLSvc/<SQL Server computer name>:1433 <Domain\Account>
setspn -A MSSQLSvc/<SQL Server FQDN>:1433 <Domain\Account>

In my case the syntax would be:

setspn –A MSSQLSvc/CRM-SQL:1433 TZOOKI\sqlsvc
setspn –A MSSQLSvc/CRM-SQL.tzooki.com:1433 TZOOKI\sqlsvc

cmd

Notes:

  • If you are running SQL with NETWORK SERVICES or NT Service\MSSQLSERVER – then you need to register the SPN’s for the machine name (it is less likely to encounter this error in that scenario – but possible) – example:
    setspn –A MSSQLSvc/CRM-SQL:1433 TZOOKI\crm-sql
  •  If you changed the default SQL port from 1433 to something else – then you need to update the commands accordingly

3. In Dynamics CRM setup click back & next – Problem should be solved – You can now continue the installation.


Another approach:

If you have issues with the CMD commands then there is a way to solve this with a simple GUI instead:
1. Connect to your Active Directory server -> open the ADSI Editor and locate your service account (or machine name if you are using NETWORK SERVICES or NT Service\MSSQLSERVER)
2. Right click -> Properties

3

3. In the Attribute Editor locate ServicePrincipalName and click Edit.
4. Add your SPN’s accordingly:

4

5. Click OK & Apply – You installation should now go through without issues

Good Luck with the rest of the installation 🙂

Microsoft Dynamics NAV 2015 Installation Guide

Hello everyone!

A new video tutorial is available on my YouTube channel – this time a step-by-step installation guide for Microsoft Dynamics NAV 2015 with SQL 2014 – Check it out:

This is a very straight-forward guide that explains how to setup a working environment with the Demo Cronus Database from Microsoft – You can use this for your Tests, Development & Presentation servers – and the installation process is also relevant for a small Production Environment. I hope you find this useful – If so – don’t forget to subscribe 🙂

Step-By-Step Dynamics CRM 2015 Installation Guide

Hey everyone!

So I finally decided to create my very first video tutorial – it’s a basic & simple installation guide for Dynamics CRM 2015  on 2 servers and you can watch it on my YouTube channel

I hope you find this helpful & useful!

More stuff coming soon!

Microsoft.Crm.CrmSecurityException: Could not find GUID for server: SERVERNAME$ With SearchFilter:samAccountName

Hi everyone!

I have stumbled into the following issue during a CRM 2013 setup: You run a regular installation and the setup completes with the following error:

Action Microsoft.Crm.Tools.Admin.ProvisionBusinessAction failed.

Once I closed the error I noticed that CRM was actually installed and all the services were running, but the Organization was in a “failed” status and was inaccessible. When I tried to delete it and recreate it – it fails again with the same error.
After a closer look at the error log I found the following entry:

Microsoft.Crm.CrmSecurityException: Could not find GUID for server: SERVERNAME$ With SearchFilter:samAccountName

So I did some googling and found a few people that encountered this problem with an ADFS deployment – but nothing solved my issue.
Eventually the problem in my case was that ports 3268 & 3269 were blocked (those are the Global Catalog LDAP & Global Catalog LDAP SSL ports) and the solution to this was to open those ports in the Firewall.

If you encounter the same issue you need to check if the required ports are open against your current Domain controller:

1. Open CMD with run as admin and type “echo %LOGONSERVER%” – this will return the DC you are authenticating with.
2. Then type Telnet dcname port# (You need to add the Telnet client feature through the server management console).
For example: telnet DC01 3268

If you receive a message that a connection cannot be made – this means the ports are blocked and need to be opened by your IT staff / Sys admin.

You should run this test for all the required protocols:

Service Name TCP
LDAP 389
LDAP SSL 636
RPC Endpoint Mapper 135
Global Catalog LDAP 3268
Global Catalog LDAP SSL 3269
Kerberos 88

In any case you should always verify that all the required ports are open according to “Connectivity and Firewall Port Requirements for Microsoft Dynamics CRM 2013” document – which you can find here:

http://www.microsoft.com/en-us/download/details.aspx?id=40324

Hope this one was informative & Helpful 🙂

Michael.

CRM 2013 Fetch XML reports not working

Here’s a scenario:

You install a fresh deployment of Dynamics CRM 2013 on one server using a domain account as the CRMApppool in IIS and Microsoft SQL with SSRS on a second server – Installation goes smoothly and everything works just fine including out-of-the-box reports – except that when you try to create and run Fetch XML reports you get the following error:

“the report cannot be displayed. (rsprocessingaborted)”

Image


Here is what you need to do (The changes that we’ll make might cause CRM to be unavailable for short periods of time):

1. Check the identity of the CRMAppPool. To do this simply click Start -> Run -> type inetmgr -> Press Enter. Expand the server name and under application pools check the CRMAppPool identity.

Image


2. You need to register an SPN for this identity – Let’s assume that the identity is domain\crmservice and the CRM server name is just crmserver.

Open CMD with “run as administrator” and type the following commands one by one:

setspn -A HTTP/crmserver domain\crmservice

setspn -A HTTP/crmserver.domain.com domain\crmservice

Important notes:

  • In the second line you need to use your domain’s FQDN – domain.com is just an example.
  • I’m assuming that you installed CRM on port 80, if not or if you are using host headers you will need to create the proper SPN’s along with the port number – for example:  setspn -A HTTP/crmserver:5555 domain\crmservice

You should get a confirmation that the SPN’s were registered successfully.


3. Browse to your SSRS URL (Probably: http://sqlserver/reports) and click ‘Details View’ on the right, then browse to:

YourOrganization_MSCRM > CustomReports > MSCRM_FetchDataSource – Inside make sure that the data type is set to ‘Microsoft Dynamics CRM Fetch’, the connection string has your Organization Name and connect using is set to ‘Credentials supplied by the user running the report’

Image

Save & Close.


4. Do an IIS reset (should work without but just in case…) Open CRM and check your FetchXML reports – they should be working now – It’s very important to check everything locally on the CRM server & remotely from clients or other server.


VERY IMPORTANT:

As we did changes in SPN’s that may mess up Kerberos authentication – you should check that CRM is available locally and from remote clients – If you are able to browse CRM locally (or using I.P) but you are getting 401 authentication error (after being asked for credentials 3-4 times) when trying to access from a different server or client using the CRM URL – do the following to resolve this:

  • On the CRM server open IIS and go to the Microsoft Dynamics CRM website -> Open the Configuration Editor

Image

  • Under Section browse to the following location – system.webServer -> Security -> Authentication -> Windows Authentication

Image

  • Inside make sure that UseAppPoolCredentials is set to True:

Image

  • Do an IIS reset on the CRM server. This procedure should resolve the 401 authentication issue and your CRM should be accessible from all clients along with the working FetchXML reports.

If from some reason your CRM started behaving “weird” or this process caused other issues you can revert all the changes we did by simply deleting the SPN’s and changing back UseAppPoolCredentials to False.

To delete the SPN’s use -D instead of -A:

setspn -D HTTP/crmserver domain\crmservice

setspn -D HTTP/crmserver.domain.com domain\crmservice

Remember that it’s best to do all those changes after working hours, as some of them might cause CRM to be unavailable. Also if you have a testing environment – it’s always better to test those things there before we do them on the production servers.

Good Luck!

CRM async service high CPU usage

There are many scenarios that can cause a high CPU utilization by the CRM asynchronous service, here are some
of the most common ones i encountered:

1. Check if the AsyncOperationBase table doesn’t have too many records in it. Once this table has millions of records – things may start working very slow. Use the following article to solve this issue and to create a proper maintenance plan to prevent this from happening:

http://support.microsoft.com/kb/968520

2. Use the CRM Advanced Find to search for locked system jobs – this is a very common issue that can cause the
async service to go havoc and utilize 100% of the CPU on the server ALL THE TIME – even when there is
absolutely zero activity in the system.

If you find any locked system jobs with the advanced find – delete them and restart the async service.

Image

3. Check the email router and the emails in the system:

Use the Advanced find to see if there are any emails stuck in sending status, if so – try deleting them and investigate why they got stuck in the first place. You should also try stopping the email router service to eliminate it as the cause and check the event log to see if there are any “suspicious” emails in the queue. Sometimes emails with special characters or some sort of corruption can cause issues with the async service (although they are not supposed to, i did encounter it).

4. RESTART! try restarting the server/asynchronous service. Sometimes restarting the system is the simplest
solution, so before you start investigating the problem and wasting hours on hours of your time – make sure you do system reboot first.

5. If none of the above helps you should try investigating further and farther.

  • Check your SQL server logs, performance & event log for any suspicious entries.
  •  Try tracing the CRM and analyze the trace file for any errors or exceptions. Use this article to enable tracing for CRM: http://support.microsoft.com/kb/907490
  • Try to see if maybe a 3rd party entity is causing the problem: Antivirus, Firewall etc.

Good Luck 🙂

Michael.