The trust relationship between this workstation and the primary domain failed Hyper-V Server

The trust relationship between this workstation and the primary domain failed

When playing around with some Hyper-V servers that have been inactive for some time, we received an error:

Screenshot 2016 01 05 19 31 45

The cause of this is due to the fact that Active Directory is doing a lot more than simple user name and password storage. We found that a Hyper-V system that remains off for some time, then is turned on again can suffer this. The reason for this has to do with the way that some applications use the Active Directory. Take Exchange Server, for example. Exchange Server stores messages in a mailbox database residing on a mailbox server. However, this is the only significant data that is stored locally on Exchange Server. All of the Exchange Server configuration data is stored within the Active Directory. In fact, it is possible to completely rebuild a failed Exchange Server from scratch (aside from the mailbox database) simply by making use of the configuration data that is stored in the Active Directory.

The suggestion by some other blogs is to: simply reset the computer account. To do so, open the Active Directory Users and Computers console and select the Computers container. Right click on the computer that you are having trouble with. Select the Reset Account command from the shortcut menu, as shown in Figure 2. When you do, you will see a prompt asking you if you are sure that you want to reset the computer account.  Click Yes and the computer account will be reset.

NewImage

This is perfectly safe to do, but is not likely to resolve the issue.

The Fix

1. Log into the server in question using the non domain admin account.

2. Open the Power Shell and run the command:

$credential = Get-Credential

(When prompted, you need to enter the domain administrator account and name.)

3. Then run the command: 

Reset-ComputerMachinePassword -Server ClosestDomainControllerNameHere

(Replacing the “ClosestDomainControllerNameHere” with your domain AD domain. domain.com for example.)

After running this you should be good to login.

CRM 2013 IFD Setup with ADFS 3.0 on Windows 2012 R2 Hosted Setup

We already have a popular post for the configuration of IFD setup with CRM 2011, and recently we updated this blog to support CRM 2015 here: 

http://www.interactivewebs.com/blog/index.php/crm/how-to-set-up-crm-2015-ifd-on-windows-2012-and-adfs-3-0/

Many of you may find that better for setting up CRM 2013 than this blog, as the data is mostly exactly the same as this blog, but some of the order of things is better described.

Upgrading from CRM 2011 to CRM 2013 and need help? InteractiveWebs offer professional Microsoft CRM Upgrade Services and Support.

The Existing Setup

Because this is a test environment, we are running the server on a Hyper V server. A single VM machine, that is running a fully patched version of:

  • Windows 2012 R2 SP2 64 Bit – (MSDN File: en_windows_server_2012_r2_x64_dvd_2707946
  • SQL 2012 R2 64 Bit – (MSDN File: en_sql_server_2012_standard_edition_with_service_pack_2_x64_dvd_4351706)
  • Microsoft CRM 2013 64 Bit – (MSDN File: en_microsoft_dynamics_crm_server_2013_sp1_x86_and_x64_4330464)

How to Install CRM 2013

We pretty much followed a combination of these instructions: http://blogs.msdn.com/b/niran_belliappa/archive/2013/11/05/step-by-step-installing-dynamics-crm-2013-on-windows-server-2012.aspx

But we needed some additional steps for the ADFS 3.0. They are mentioned below.

We then Patched the Server to latest updates, then ran SP1 for CRM 2103. http://support.microsoft.com/kb/2941390

Importantly

When we setup CRM, we selected the option to NOT use the default website, but configure a new one with the default settings of port 5555. This is necessary as you will see later.

Backup First

In all things Microsoft world, it is vital what you establish a working point to avoid unnecessarily installing things all over again. To get things working we have started fresh over 4 times.

Hyper V is great for this, as we just stopped the server, and made a copy of the VHD file. Then when it is time to start all over, it is just a matter of restoring from copy/backup.

Test First

Test that your CRM setup is working. Go to the local computer name (ours is VSERVER07) on the correct port: http://vserver07:5555

We called our Deployment of CRM – “CRM2013″ So the URL redirects to: http://vserver07:5555/CRM2013/main.aspx

and after being prompted for login, we are in and testing.

Screenshot 2014 07 05 16 16 21

 

Apply a Wildcard SSL Certificate

In CRM, the accessing of deployments is handled by the sub domains. So if we call a deployment “business1″ we will access that as: https://business1.domain.com

For testing, we purchased a standard Wildcard SSL certificate that applied that to the IIS7 server.

We uses Start SSL who provide cheap as you find on the net (free) but requires you to jump through a LOT of hoops to get familiar with issuing certificates.

Application for a certificate

Here, I will be a wildcard certificate, for example, describes how to create a certificate:

1) Open IIS Manager

2) Click the server name in the main screen double click Server Certificates

3) In the right panel, click Create Certificate Request…

image

4) fill in the following diagram each column, click Next

image

5) Cryptographic Service Provider Properties page change the Bit Length to 2048 click Next.

Screenshot 2014 07 05 18 50 18

6) In the File Name page, enter C: \ req.txt , and then click Finish. (You can save it any place you like, with any name)

7) Open the certificate in Notepad, and copy the contents.

Screenshot 2014 07 05 18 53 05

This is the text that is pasted into the Start SSL Certificate request page to generate the certificate:

Screenshot 2014 07 05 18 55 03

8) After you finish generating the certificate text in StartSSL.com you get a bunch of code that looks similar to the request code. Copy that generated code

9) Paste the code back into a new Text / Notepad Document on the Web server, but call it something that ends in .cer  (not .txt).

10) back to the IIS Manager, click No. 3)  Step graph Complete Certificate Request …

11) Select the the file you created at point 9 above to complete the request.

12) Click OK.

So that we completed the wildcard certificate request, and import of the new .CER certificate, ready for use.

Binding site for the default SSL certificate

1) Open IIS Manager.

2) In the Connections panel, expand Sites , click Default Web Site.

3) In the Actions pane, click Bindings.

image

4) In the Site Bindings dialog box, click Add.

5) Type select HTTPS.

6) SSL Certificate , select the certificate you just created *. contoso.com , and then click OK.

image Ours is interactivewebs.com

7) Click Close.

For the CRM 2013 binding site SSL certificate

This is in effect repeating the above process like you did for the default certificate, but using a different port (444 for example).

1)Open IIS Manager.

2) In the Connections panel, expand Sites , click CRM Web Site.

3) In the Actions pane, click Bindings.

4) In the Site Bindings dialog box, click Add.

5) Type select HTTPS.

6) SSL Certificate , select the certificate you just created *. contoso.com .

7) Port to select a different 443 (e.g. 444 ) and port number, and then click OK

 Screenshot 2014 07 05 19 22 30

8) Click Close.

DNS configuration

We are going to add a few DNS “A” records so that the records listed in point 1-4 below in DNS Goal are resolving correctly to the IP address of your CRM server.

There are two ways you can achieve the desired result. But first lets understand the desired result.

  1. We make the assumption that your server is running at least one static IP address.
  2. Because this is Internet Facing, that IP needs to be accessible to the world.
  3. That same IP can be used for access to your server both internally on the matching we are playing with, and externally form anyone on the net.
Lets Get Basic

Start a Command Prompt, and work out what your IP address of the server is.

Click START > RUN > CMD

Type IPCONFIG – Enter

Under the name: IPv4 Address is a number that looks like: 66.34.204.220

image

That is Your IP Address of the Server.

The DNS Goal

Make sure that when you PING xxx.domain.com that it points to that IP address. Both for the world and for you when you do that on your server.

(xxx is the sub domain that we are about to configure.)

To configure CRM, we need some sub domains to point to the server IP.

Adding records in DNS like this:

Screenshot 2014 07 05 19 28 02

  1. sts1.domain.com
  2. auth.domain.com
  3. dev.domain.com
  4. Your ORG name.  org.domain.com (Where ORG is the CRM deployment name of your organization or organizations), e.g.
  5. internalcrm.domain.com (used later for internal definition of the CRM server access).
  6. adfs.domain.com (used for reference to the ADFS server)
  7. one for the root domain so that domain.com points to the same server. (This is for the ADFS logout URL)

Screenshot 2014 07 10 18 04 02

We have two setup here: CRM and CRM2013. So we need to configure crm.iwebscrm.com and crm2013.iwebscrm.com.

Test DNS

You must be able to ping all of those names and get the correct server IP address. Both from computers on the internet, and from the server.

Note: If you have added the DNS records, but still encounter name resolution problems, you can try running on the client ipconfig / flushdns to clean up the cache. You can also click the DNS server root and click CLEAR CACHE so that the server is responding with the latest updates.

image

Note: Don’t bother proceeding past this step if you cannot ping your sub domains internally and externally correctly.

Firewall configuration

You need to set the firewall to allow the CRM 2013 and the AD FS 2.0 port used by the incoming data stream. HTTPS (SSL) is the default port 443.

For Initial setup testing etc. We recommend just turning the thing off. Better start from a place where it does not muck you around, then turn it all back on after you are successful.

1) Control Panel

2) Search Firewall

3) Check Firewall Status

4) Turn Off or On Firewall

Screenshot 2014 07 05 19 33 53

Just turn it all off for now. (Remember to come back, turn it on and allow access for the unusual port 444 that you configured earlier for the SSL on the CRM site.

Configuration Claim-based authentication internal access

Configure the internal access Claim-based authentication requires the following steps:

  • Install and configure AD FS 3.0
  • Set Claims-based authentication configuration CRM 2013 server.
  • Set the Claims-based authentication configuration AD FS 3.0 server.
  • Test claims-based authentication within the access.

Install and configure ADFS 3.0

CRM 2013 with a variety of STS provider ( STS Provider ) together. This article uses Active Directory Federation Services (AD FS) 3.0 to provide a security token service (security token service ).

Note: AD FS 2.0 will be installed to the default site, so install AD FS 3.0 , you must have CRM 2013 installation in the new site. (Remember we said that earlier)

IIS Looks like this if it is correctly installed: image

If you only see the default website with CRM installed in that. Start AGAIN!

Install ADFS Server Role

From Server Manager – Add A Server role for: Active Directory Federation Services

Screenshot 2014 07 05 19 39 54

After if Finishes:

Screenshot 2014 07 05 19 41 52

Click the Configure the Federation Services on this server.

Configure AD FS 3.0

1 Click on Configure the federation service on this server.

2 In the AD FS 3.0 Management page , click AD FS 3.0 Federation Server Configuration Wizard .

3 In the Welcome page , select Create the first federation server in a federation server farm, and then click Next.

Screenshot 2014 07 05 19 43 52

4 Select next to continue with the current administrator (must be a domain admin).

Screenshot 2014 07 10 16 34 34

5 Choose your SSL certificate (the choice of a certificate created *.domain.com ) ,add a Federation Service name ( for example , sts1.contoso.com), and Select a Service Display Name for your business – selecting the one that is NOT starting with a *, then click Next.

Screenshot 2014 07 10 16 36 32

6 Open PowerShell and run the following command: “Add-KdsRootKey -EffectiveTime (Get-Date).AddHours(-10)”

 Screenshot 2014 07 10 16 40 55

If you don’t you will se the error: Group Managed Service Accounts are not available because the KDS Root Key has not been set.

7 Create a database on this server using Windows Internal Database, click Next.

Screenshot 2014 07 10 16 43 30

Or use the local SQL instance etc if you have one.

Screenshot 2014 07 31 22 00 47

8 Review Options click Next

Screenshot 2014 07 10 16 44 45

9 Pre-requisits checklist, click Configure

Screenshot 2014 07 10 16 45 44

10 You should see a message that “This Server was successfully configured

Verify the AD FS 3.0 is working

Follow the steps below to verify that the AD FS 3.0 is working :

1 Open Internet Explorer.

2 Enter the federation metadata of the URL , for example:

https://adfs.iwebscrm.com/federationmetadata/2007-06/federationmetadata.xml

(Where sts1.contoso.com represents the DNS A record we setup earlier.  sts1.yourdomainname.com)

3. to ensure that no certificate associated with the warning appears, and you can view the certificate to be sure it is showing.

Screenshot 2014 07 31 18 22 17Screenshot 2014 07 31 18 23 18

Claims-based authentication configuration CRM 2013 server

After you install and configure the AD FS 3.0 , we need to configure the Claims-based authentication before setting CRM 2013 binding types ( Binding type ) and the root domain (root Domains) .

Following these steps to set up CRM 2013 bound for the HTTPS and configure the root domain address :

1 Open the CRM Deployment Manager.

2 In the Actions pane , click Properties .

Screenshot 2014 07 10 17 07 03

3 Click the Web Address page.

4 In the Binding Type , select HTTPS .

Screenshot 2014 07 10 17 09 07

5. You can most likely select Apply at this point, and the default internal address for the CRM will work fine. We however created a new A record in the DNS for “internalcrm” and pointed it to this new server. This allows us to user a clear path for the internal URL.

6 For example, *. contoso.com wildcard certificate, you can useinternalcrm.contoso.com:444 as the network address.

Screenshot 2016 01 10 22 03 10

7 Click OK.

8 In the Deployment Manager console tree, right-click Microsoft Dynamics CRM, and then click Configure Claims-Based Authentication.

Screenshot 2014 07 10 17 59 37

9 Click Next on the Welcome page

10  On the Specify the security token service page, enter the Federation metadata URL, such as https://adfs.fabrikam.com/federationmetadata/2007-06/federationmetadata.xml. In our case because we setup a DNS record for “adfs” we are going to use that: https://adfs.iwebscrm.com/federationmetadata/2007-06/federationmetadata.xml

Screenshot 2014 07 10 18 08 28

11 Click Next then select the certificate that we created perviously for the *.domain connection

Screenshot 2014 07 10 18 07 28

12 Select Next 

Screenshot 2014 07 10 18 09 58

13 Select Apply then Finish

Screenshot 2014 07 10 18 10 31

Screenshot 2014 07 10 18 11 45

14 IMPORTANT – Click View Log File

15 Scroll to the end, and Copy the URL from the bottom of the file.

image– This will be used in the next configuration. Note that this is different to the URL used in step 4 above, as it represents the internal URL. Subtle but vital (and the cause of frustration the first 10 times we tried this). In our case the URL looked like this: https://adfs.iwebscrm.com/federationmetadata/2007-06/federationmetadata.xml

16 Click Finish.

17 Validate that you can browse to the URL above. If you cannot view this in a browser, then have a look again at your permissions on the certificate in relation to the account on the application pool in IIS for CRM. Read above: Claims-based authentication configuration CRM 2013server.

18. Once you can browse this URL, you are done here.

Claims-based authentication configuration AD FS 3.0 server

After completion of the previous step, the next step we need AD FS 3.0 to add and configure the statement provider trust ( claims Provider trusts ) and the relying party trust ( Relying Party trusts ).

Configure claims provider trusts

Start AD FS 3.0 Management. In the Navigation Pane, expand Trust Relationships, and then click Claims Provider Trusts. Under Claims Provider Trusts, right-click Active Directory, and then click Edit Claims Rules.

Screenshot 2014 07 10 18 27 02

 

In the Rules Editor, click Add Rule, In the Claim rule template list, select the Send LDAP Attributes as Claims template, and then click Next

Screenshot 2014 07 10 18 27 33

 

Step10: Create the following rule

Claim rule name: UPN Claim Rule (or something descriptive) Attribute store: Active Directory LDAP Attribute: User Principal Name Outgoing Claim Type: UPN

Screenshot 2014 07 10 18 34 58

Click Finish, and then click OK to close the Rules Editor

After you enable claims-based authentication, you must configure Dynamics CRM Server 2013 as a relying party to consume claims from AD FS 3.0 for authenticating internal claims access.

Start AD FS Management. On the Actions menu located in the right column, click Add Relying Party Trust. In the Add Relying Party Trust Wizard, click Start.

On the Select Data Source page, click Import data about the relying party published online or on a local network, and then type the URL you copied earlier from the log file. So that will be https://internalcrm.domain.com/FederationMetadata/2007-06/FederationMetadata.xml. This is the same internalcrm A recored that we checked earlier in the process.

Screenshot 2014 07 10 18 38 23

On the Specify Display Name page, type a display name, such as CRM Claims Relying Party, and then click Next.

Screenshot 2014 07 10 18 40 57

Click Next on the multi-factor authentication options.

Screenshot 2014 07 10 18 41 35

On the Choose Issuance Authorisation Rules page, leave the Permit all users to access this relying party option selected, and then click Next.

Screenshot 2014 07 10 18 41 44

On the Ready to Add Trust page, click the checkbox option to Open the Edit Claim Rules, Next, and then click Close.

Screenshot 2014 07 10 18 42 10

The Rules Editor appears, click Add Rule. Otherwise, in the Relying Party Trusts list, right-click the relying party object that you created, click Edit Claims Rules, and then click Add Rule.

Screenshot 2014 07 10 18 42 52

In the Claim rule template list, select the Pass Through or Filter an Incoming Claim template, and then click Next.

Screenshot 2014 07 10 18 44 21

Create the following Rule #1 Claim rule name: Pass Through UPN (or something descriptive) Incoming claim type: UPN Pass through all claim values

Click Finish.

Screenshot 2014 07 10 18 44 59

Screenshot 2014 07 10 18 50 07

In the Rules Editor, click Add Rule, in the Claim rule template list, select the Pass Through or Filter an Incoming Claim template, and then click Next

Screenshot 2014 07 10 18 50 26

Create the following Rule #2

Claim rule name: Pass Through Primary SID (or something descriptive) Incoming claim type: Primary SID Pass through all claim values

Click Finish

Screenshot 2014 07 10 18 51 11

Screenshot 2014 07 10 18 51 23

In the Rules Editor, click Add Rule. In the Claim rule template list, select the Transform an Incoming Claim template, and then click Next.

Screenshot 2014 07 10 18 51 59

Create the following rule #3

Claim rule name: Transform Windows Account Name to Name (or something descriptive) Incoming claiming type: Windows account name Outgoing claim type: Name Pass through all claim values

Screenshot 2014 07 10 18 53 05

Click Finish, and when you have created all three rules, click OK to close the Rules Editor.

Screenshot 2014 07 10 18 53 20

So now we have claims setup for CRM.

ADFS 3.0 Extra Steps

To say these steps are “fucking important” is to under estimate the value I place in the 2 weeks it took me to resolve the ADFS 3.0.

Enable Forms Authentication

AD FS in Windows Server 2012 R2, forms authentication is not enabled by default.

1. Log on to the AD FS server as an administrator.

2. Open the AD FS management console and click Authentication Policies.

3. Under Primary Authentication, Global Settings, Authentication Methods, click Edit.

4. Under Intranet, enable (check) Forms Authentication.

Screenshot 2014 08 02 18 06 40

 

Add the ADFS server to the Local intranet zone.

1. In Internet Explorer, click Tools, and then click Internet Options.

2. Click the Security tab, click the Local intranet zone, and then click Sites.

3. Click Advanced.

4. In Add this website to the zone, type the URL for your AD FS server, for example, https://sts1.contoso.com.

5. Click Add, click Close, and then click OK. 

6. Select the Advanced tab. Scroll down and verify that under Security Enable Integrated Windows Authentication is checked.

7. Click OK to close the Internet Options dialog box.You will need to update the Local intranet zone on each client computer accessing Microsoft Dynamics CRM data internally. To use Group Policy to push this setting to all domain-joined internal client computers do the following.

 

Test claims-based authentication within the access

You should now be able to use the claims certified to the internal access CRM 2013

1 Open the Deployment Manager.

2 Expand the Deployment Manager node , and then click onOrganizations .

3 Right-click your organization , and then click Browse . so you can open the CRM web page of ( for example:https://internalcrm.contoso.com:444 ).

image

Screenshot 2014 08 02 18 10 57

Trouble Shooting

If the CRM web page can not be displayed, then run the following iisreset and then try again.

image

If the CRM web page still does not show, then you may need to setup AD FS 3.0 server setup a SPN (Service Principal Name) . Re-run the Claims-Based Authentication Wizard, and then browse to the Specify the security token service page, note the AD FS 3.0 server in the Federation metadata URL in the name. (In this case sts1.interactivewebs.com )

http://blogs.msdn.com/b/crm/archive/2009/08/06/configuring-service-principal-names.aspx

image

1 Open a command line tool .

2 Enter the following command : ( application, in your own environment, substitute the name of the name of the command line )

c: \> setspn -a http/sts1.interactivewebs.com fserver4\VSERVER08$

fserver4\VSERVER08 = the domain and machine name of the server.

image

c: \> iisreset

3 and then re-access the Microsoft Dynamics CRM Server 2013 site, so you should be able to successfully access to the CRM 2013 Web page.

http://technet.microsoft.com/en-us/library/gg188614.aspx

If you receive ADFS – sts1 errors.

There was a problem accessing the site. Try to browse to the site again. If the problem persists, contact the administrator of this site and provide the reference number to identify the problem. Reference number: xxx

And or if you look in your log files under ADFS 2.0 You will see errors like this.

image

In our case, this was because we used the external Metadata URL and not the Internal URL that we should have copied from the “View Log File” When configuring the Claims Based Authentication. Step 14 in the section above.

image

image

Note the difference between this:

https://internalcrm.interactivewebs15.com:444/FederationMetadata/2007-06/FederationMetadata.xml

and the original meta data check we did with:

https://sts1.interactivewebs15.com/federationmetadata/2007-06/federationmetadata.xml

We incorrectly figured it would be pulling the same XML data. It does NOT!

Configuration Claim-based authentication external access

Open to the CRM 2013 Data Claims-based authentication of external access, you need to do the following steps:

1 complete contents of the previous section: Configuring Claim-based authentication- internal access.

2 for the IFD configuration CRM 2013 server.

3 for the IFD configuration AD FS 3.0 server.

4 Test claims-based authentication external access.

The IFD configuration CRM 2013 server

When opening Claims certified internal access, you can open by IFD external claims visited. The following describes using the IFDConfiguration Wizard to configure, if you want to learn how to use PowerShell to be configured, refer to the English original.

1 Open the Deployment Manager.

2 In the tree structure , right-click Microsoft Dynamics CRM , and then click Configure Internet-Facing Deployment.

Screenshot 2014 08 02 18 14 52

3 Click Next.

Screenshot 2014 08 02 18 15 20

4 Fill in the correct domain information for the Web Application, Org, and Discovery Web services. Remembering here that in our case: *.interactivewebs.com was the name of the wildcard certificate used, and that PORT 444 was the port we configured for the CRM Web Instance in the bindings for IIS.

Thus we use:

  • Web Application Server Domain: interactivewebs.com:444
  • Organization Web Service Domain: interactivewebs.com:444
  • Web Service Discovery Domain: dev.interactivewebs.com:444

Note – Enter the domain name, rather than the server name .

  • If the CRM installed on the same server or servers are installed in the same domain, then the Web Application Server Domain and Organization Web Service Domain should be the same .
  • Web Service Discovery Domain must be a Web Application Server Domain as a subdomain like the  “dev.” that we setup in DNS earlier.
  • domain name must be on the SSL certificate name

Domain examples :

  • Web Application Server Domain: contoso.com: 444
  • Organization Web Service Domain: contoso.com: 444
  • Web Service Discovery Domain: dev.contoso.com: 444

Screenshot 2014 08 02 18 16 57

For more information on the website, please refer to Install Microsoft Dynamics CRM Server 2013 on multiple computers(http://go.microsoft.com/fwlink/?LinkID=199532 )

5 In the Enter the external domain where your Internet-facing servers are located input box , enter for your internet to CRM 2013 server located outside the domain of information, and then click Next.

Screenshot 2014 08 02 18 18 00

You must specify the domain specified in the previous step Web Application Server Domain sub-domains . default , will be “auth.” added to the Web Application Server Domain before.

Domain examples :

  • External Domain: auth.contoso.com: 444

6 In the System Checks page , if there is no problem, click Next.

Screenshot 2014 08 02 18 18 43

7 In Review your selections and then click Apply page , confirm your input , and then click Apply.

Screenshot 2014 08 02 18 19 12

8 Click Finish .

Screenshot 2014 08 02 18 19 37

9. Open a command line tool, run: iisreset

The IFD configuration AD FS 3.0 server

After you have enabled IFD on the Microsoft Dynamics CRM Server 2013 you will need to create a relying party for the IFD endpoint on the AD FS server. (Steps below are from the MSDN Blog.

Step6: Start AD FS Management. On the Actions menu located in the right column, click Add Relying Party Trust. In the Add Relying Party Trust Wizard, click Start.

image

Step7: On the Select Data Source page, click Import data about the relying party published online or on a local network, and then type the URL to locate the federationmetadata.xml file. This federation metadata is created during IFD Setup.

For example, https://auth.fabrikam.com/FederationMetadata/2007-06/FederationMetadata.xml.

Type this URL in your browser and verify that no certificate-related warnings appear.

image

Step8: On the Specify Display Name page, type a display name, such as CRM IFD Relying Party, and then click Next

image

Step9: On the Choose Issuance Authorization Rules page, leave the Permit all users to access this relying party option selected, and then click Next.

image

Step10: On the Ready to Add Trust page, click Next, and then click Close.

image

Step11: If the Rules Editor appears, click Add Rule. Otherwise, in the Relying Party Trusts list, right-click the relying party object that you created, click Edit Claims Rules, and then click Add Rule

image

Step12: In the Claim rule template list, select the Pass Through or Filter an Incoming Claimtemplate, and then click Next.

image

Step13: Create the following rule#1

Claim rule name: Pass Through UPN (or something descriptive)

Incoming claim type: UPN

Pass through all claim values

Click Finish

image

Step14: In the Rules Editor, click Add Rule, and in the Claim rule template list, select the Pass Through or Filter an Incoming Claim template, and then click Next

image

Step15: Create the following rule#2

Claim rule name: Pass Through Primary SID (or something descriptive)

Incoming claim type: Primary SID

Pass through all claim values

Click Finish

image

Step16: In the Rules Editor, click Add Rule. In the Claim rule template list, select the Transform an Incoming Claim template, and then click Next.

image

Step17: Create the following rule #3

Claim rule name: Transform Windows Account Name to Name (or something descriptive)

Incoming claim type: Windows account name

Outgoing claim type: * Name  (Note that “* Name”  without the “” is required to be typed)

Pass through all claim values

Click Finish, and when you have created all three rules, click OK to close the Rules Editor.

image

Test claims-based authentication to access external

Now, you should use the claims certified external access CRM 2013 a. In IE the browser CRM 2013 external address (for example: https://org.contoso.com:444 ), you will see the following pages:

Screenshot 2014 08 02 18 24 18

Enter the user name password, log CRM 2013.

Screenshot 2014 08 29 01 02 28

Fix the MEX Endpoint

When you browse externally to the URL: https://sts1.iwebscrm.com/adfs/services/trust/mex

Where “sts1.yourorg.com” replaces ours… you should see an XML endpoint return. We found that after setup of CRM 2013 in the above mentioned environment there was a conflict with the Sandbox port 808 and this caused the failure of the service, giving a 503 error for /adfs/services/trust/mex

The solution is simple: Run the following command in PowerShell

Set-ADFSProperties –nettcpport 809

Then restart ADFS from the Services, or restart the server. Reference: http://www.interactivewebs.com/blog/index.php/crm-2013/adfsservicestrustmex-returns-503-on-crm-2013-windows-2012-ifd-mex-endpoint-fix/

 

Microsoft CRM IFD Event 364 and 111 in ADFS

Microsoft CRM IFD Event ID 364 and 111

We got the ADFS login screen as expected, but on trying to login we received an error:

  • Activity ID: 00000000-0000-0000-0400-0080020000f4
  • Relying party: CRM IFD Relying Party

Screenshot 2016 01 11 19 45 56

Associate with two errors in the ADFS Event Log.

Event ID: 111

Additional Data 
Exception details: 
System.ArgumentException: ID4216: The ClaimType ‘* Name’ must be of format ‘namespace’/’name’.
Parameter name: claimType
at Microsoft.IdentityModel.Threading.AsyncResult.End(IAsyncResult result)
at Microsoft.IdentityModel.Threading.TypedAsyncResult`1.End(IAsyncResult result)
at Microsoft.IdentityModel.SecurityTokenService.SecurityTokenService.EndIssue(IAsyncResult result)
at Microsoft.IdentityServer.Web.WSTrust.SecurityTokenServiceManager.Issue(RequestSecurityToken request, IList`1& identityClaimSet)

 Event ID: 364

Encountered error during federation passive request.

Additional Data

Protocol Name: 
wsfed

Relying Party: 
https://crm2016.iwebscrm16.com:444/

Exception details: 
Microsoft.IdentityServer.RequestFailedException: MSIS7012: An error occurred while processing the request. Contact your administrator for details. —> System.ArgumentException: ID4216: The ClaimType ‘* Name’ must be of format ‘namespace’/’name’.
Parameter name: claimType
at Microsoft.IdentityModel.Threading.AsyncResult.End(IAsyncResult result)
at Microsoft.IdentityModel.Threading.TypedAsyncResult`1.End(IAsyncResult result)
at Microsoft.IdentityModel.SecurityTokenService.SecurityTokenService.EndIssue(IAsyncResult result)
at Microsoft.IdentityServer.Web.WSTrust.SecurityTokenServiceManager.Issue(RequestSecurityToken request, IList`1& identityClaimSet)
at Microsoft.IdentityServer.Web.Protocols.PassiveProtocolHandler.SubmitRequest(MSISRequestSecurityToken request, IList`1& identityClaimCollection)
at Microsoft.IdentityServer.Web.Protocols.PassiveProtocolHandler.RequestBearerToken(MSISRequestSecurityToken signInRequest, Uri& replyTo, IList`1& identityClaimCollection)
at Microsoft.IdentityServer.Web.Protocols.WSFederation.WSFederationProtocolHandler.RequestBearerToken(MSISSignInRequestMessage signInRequest, SecurityTokenElement onBehalfOf, SecurityToken primaryAuthToken, SecurityToken deviceSecurityToken, String desiredTokenType, WrappedHttpListenerContext httpContext, Boolean isKmsiRequested, Boolean isApplicationProxyTokenRequired, MSISSession& session)
at Microsoft.IdentityServer.Web.Protocols.WSFederation.WSFederationProtocolHandler.BuildSignInResponseCoreWithSerializedToken(MSISSignInRequestMessage wsFederationPassiveRequest, WrappedHttpListenerContext context, SecurityTokenElement signOnTokenElement, Boolean isKmsiRequested, Boolean isApplicationProxyTokenRequired)
at Microsoft.IdentityServer.Web.Protocols.WSFederation.WSFederationProtocolHandler.BuildSignInResponseCoreWithSecurityToken(WSFederationSignInContext context, SecurityToken securityToken, SecurityToken deviceSecurityToken)
at Microsoft.IdentityServer.Web.Protocols.WSFederation.WSFederationProtocolHandler.BuildSignInResponse(WSFederationSignInContext federationPassiveContext, SecurityToken securityToken, SecurityToken deviceSecurityToken)
— End of inner exception stack trace —
at Microsoft.IdentityServer.Web.Protocols.WSFederation.WSFederationProtocolHandler.BuildSignInResponse(WSFederationSignInContext federationPassiveContext, SecurityToken securityToken, SecurityToken deviceSecurityToken)
at Microsoft.IdentityServer.Web.Protocols.WSFederation.WSFederationProtocolHandler.Process(ProtocolContext context)
at Microsoft.IdentityServer.Web.PassiveProtocolListener.ProcessProtocolRequest(ProtocolContext protocolContext, PassiveProtocolHandler protocolHandler)
at Microsoft.IdentityServer.Web.PassiveProtocolListener.OnGetContext(WrappedHttpListenerContext context)

System.ArgumentException: ID4216: The ClaimType ‘* Name’ must be of format ‘namespace’/’name’.
Parameter name: claimType
at Microsoft.IdentityModel.Threading.AsyncResult.End(IAsyncResult result)
at Microsoft.IdentityModel.Threading.TypedAsyncResult`1.End(IAsyncResult result)
at Microsoft.IdentityModel.SecurityTokenService.SecurityTokenService.EndIssue(IAsyncResult result)
at Microsoft.IdentityServer.Web.WSTrust.SecurityTokenServiceManager.Issue(RequestSecurityToken request, IList`1& identityClaimSet)
at Microsoft.IdentityServer.Web.Protocols.PassiveProtocolHandler.SubmitRequest(MSISRequestSecurityToken request, IList`1& identityClaimCollection)
at Microsoft.IdentityServer.Web.Protocols.PassiveProtocolHandler.RequestBearerToken(MSISRequestSecurityToken signInRequest, Uri& replyTo, IList`1& identityClaimCollection)
at Microsoft.IdentityServer.Web.Protocols.WSFederation.WSFederationProtocolHandler.RequestBearerToken(MSISSignInRequestMessage signInRequest, SecurityTokenElement onBehalfOf, SecurityToken primaryAuthToken, SecurityToken deviceSecurityToken, String desiredTokenType, WrappedHttpListenerContext httpContext, Boolean isKmsiRequested, Boolean isApplicationProxyTokenRequired, MSISSession& session)
at Microsoft.IdentityServer.Web.Protocols.WSFederation.WSFederationProtocolHandler.BuildSignInResponseCoreWithSerializedToken(MSISSignInRequestMessage wsFederationPassiveRequest, WrappedHttpListenerContext context, SecurityTokenElement signOnTokenElement, Boolean isKmsiRequested, Boolean isApplicationProxyTokenRequired)
at Microsoft.IdentityServer.Web.Protocols.WSFederation.WSFederationProtocolHandler.BuildSignInResponseCoreWithSecurityToken(WSFederationSignInContext context, SecurityToken securityToken, SecurityToken deviceSecurityToken)
at Microsoft.IdentityServer.Web.Protocols.WSFederation.WSFederationProtocolHandler.BuildSignInResponse(WSFederationSignInContext federationPassiveContext, SecurityToken securityToken, SecurityToken deviceSecurityToken)

ADFS EVENT 111

The Fix: 

This was caused because we initially had the Transform of Windows Account Name to Name was initially set as * Name rather than just Name. So we updated it (and the instructions above to allow people to not experience this problem.

Update the Relying Party Trusts / Edit Claim Rules / Transform Windows Account Name to Name – Change the name value form * Name to Name

Name to Name

Restart ADFS Service and IIS. And you should resolve these errors.

Microsoft CRM Restore Database Failed Only Enterprise edition of SQL Server supports partitioning

Upgrading from CRM 2011 to CRM 2013 you cannot restore SQL on a Non Enterprise Server

An exception occurred while executing a Transact-SQL statement or batch. (Microsoft.SqlServer.ConnectionInfo)Database ‘Org_MSCRM’ cannot be started in this edition of SQL Server because it contains a partition function ‘AuditPFN’. Only Enterprise edition of SQL Server supports partitioning. Database ‘Org_MSCRM’ cannot be started because some of the database functionality is not available in the current edition of SQL Server. (Microsoft SQL Server, Error: 905)

CAUSE

When Microsoft Dynamics CRM 2011 is installed using a Microsoft SQL Server Enterprise edition, a partition is created for the auditing functionality of Dynamics CRM 2011. The AuditBase table uses partitioning which is only available for Microsoft SQL Server Enterprise.RESOLUTIONUse the following Steps and Script to remove the partitioning. The following script recreates all the indexes on the Primary partition and then drops the partition.
Be sure to have a database backup of the ‘Org_MSCRM’ before performing the following steps. 

Fix

1. Restore the ‘Org_MSCRM’ database to a Microsoft SQL Server Enterprise edition. It is recommended to backup and restore the database instead of running the script on the production database.

2. Run the following script against the restored database.

 

IF EXISTS (SELECT name FROM sys.partition_schemes WHERE name='AuditPScheme') BEGIN SELECT CASE WHEN ind.type != 1 THEN 'DROP INDEX [dbo].[AuditBase].' + QUOTENAME(ind.name) + ' ' ELSE ' ' END + 'CREATE ' + CASE is_unique WHEN 1 THEN 'UNIQUE ' ELSE '' END + ind.type_desc + ' INDEX ' + QUOTENAME(ind.name COLLATE SQL_Latin1_General_CP1_CI_AS ) + ' ON [dbo].' + QUOTENAME(OBJECT_NAME(object_id)) + ' (' + REVERSE(SUBSTRING(REVERSE(( SELECT name + CASE WHEN sc.is_descending_key = 1 THEN ' DESC' ELSE ' ASC' END + ',' FROM sys.index_columns sc JOIN sys.columns c ON sc.object_id = c.object_id AND sc.column_id = c.column_id WHERE OBJECT_NAME(sc.object_id) = 'AuditBase' AND sc.object_id = ind.object_id AND sc.index_id = ind.index_id ORDER BY index_column_id ASC FOR XML PATH('') )), 2, 8000)) + ')' + CASE WHEN ind.type = 1 THEN ' WITH (DROP_EXISTING = ON) ON [PRIMARY]' ELSE ' ' END as Script INTO #indexesScript FROM sys.indexes ind JOIN sys.partition_schemes ps on ind.data_space_id=ps.data_space_id WHERE OBJECT_NAME(object_id) = 'AuditBase' AND ps.name = 'AuditPScheme' AND is_unique_constraint = 0 SELECT * FROM #indexesScript DECLARE @recreateScript nvarchar(max) DECLARE indScript CURSOR FOR SELECT Script FROM #indexesScript OPEN indScript FETCH NEXT FROM indScript INTO @recreateScript WHILE @@FETCH_STATUS = 0 BEGIN BEGIN TRANSACTION t1 Execute sp_executesql @recreateScript IF @@ERROR > 0 BEGIN ROLLBACK TRAN t1 declare @message varchar(max) set @message = 'Audit history recreate index failed. SQL: ' + @recreateScript RAISERROR (@message, 10,1) END ELSE BEGIN COMMIT TRAN END FETCH NEXT FROM indScript INTO @recreateScript END DROP PARTITION SCHEME AuditPScheme DROP PARTITION FUNCTION AuditPFN CLOSE indScript DEALLOCATE indScript DROP TABLE #indexesScript END

 

3. Once the script is complete you can backup the database and now you should be able to restore the database to a Microsoft SQL Server Standard edition.

Update ADFS SSL Certificates Microsoft CRM 2013 2015 and 2016 IFD

How to Update SSL Certificates for AD FS 3.0 in CRM IFD

Introduction

Microsoft Dynamics CRM can be configured to use SSL (Secure Sockets Layer). For this to work, an SSL certificate is required.

Certificates can be purchased from certificate providers and will expire after a certain period of time. Once this time has elapsed, Microsoft Dynamics CRM will no longer work until the certificate is updated.

This article describes the process to update the certificate for Microsoft Dynamics CRM

Installing the new certificate

You will need to import your certificate into the local certificate store on each CRM server that uses web services, and the AD FS server if claims-based authentication is enabled.

CertificateStore

Instructions on how to import a certificate can be obtained from your certificate provider.

Note: Problems may occur if you do not remove the old certificate.

Add permission to the certificate

It is necessary to grant specific permissions to the certificate to allow service accounts access.

Manage Private Keys

The following steps show how to add permissions to the certificate.

  1. Open the Certificate Console on the server.
  2. Check out the Microsoft Wiki for help
  3. Navigate to (Local Computer) > Personal > Certificates
  4. Right click the new certificate. Go to All Tasks > Manage Private Keys
  5. Add following permissions
    • AD FS Server: CRMAppPool Account = “Read”
    • AD FS Server: ADFSAppPool Account = “Full”
    • CRM Server: CRMAppPool Account = “Read”
    • In our case we were using the NETWORK SERVICE account and need to add the Read permissions
       Screenshot 2016 07 07 23 39 44

Update IIS (Internet Information Services) to use the new certificate

On the Microsoft Dynamics CRM website, the certificate bindings will need to be updated.

IIS Select Certificate

The following steps show how to bind the new certificate using IIS 8.

  1. Log on to the Microsoft Dynamics CRM Server.
  2. Open IIS.
  3. Locate the Microsoft Dynamics CRM website.
  4. Right click the website and click Edit Bindings.
  5. Select HTTPS and click Edit….
  6. Select the new certificate and click OK to save the settings.
  7. Close all open windows.

Reconfigure Claims-Based Authentication

The Microsoft Dynamics CRM application will need to be updated to use the new certificate.

Claims Setting

The following steps show how to reconfigure claims-based authentication.

  1. Open Deployment Manager
  2. Click Configure Claims-Based Authentication to open the wizard
  3. Click Next on the Welcome page
  4. Click Next on the Token Service page
  5. Select the new certificate on the Select Certificate page
  6. Click Next to complete the configuration

Update AD FS (Active Directory Federation Services)

In AD FS, the Service Communication certificate will need to be updated.

ADFS Certificate

The following steps show how to update the Service Communication certificate in AD FS 2.0.

  1. Open AD FS 2.0
  2. Navigate to AD FS 2.0 > Service > Certificates
  3. Click Set Service Communications Certificate
  4. Select the certificate and click OK

Update Relying Party Trusts

The Relying Party Trusts in the AD FS Management needs to be checked that the Relying Party Trusts are not showing an ! next to the listed Claims Relying Party Trust and the IFD Relying Party.

If they are, or even just to be safe. Click on each separately and the “Update from Federation Meta Data”

Screenshot 2016 07 07 23 43 26

Once these have both been updated you can move onto the last task.

Final Tasks

To finish the process, all affected services will need to be restarted.

IISRESET

The following steps should be completed once the certificate has been updated.  It may also be necessary to follow these steps if problems occur during any of the previous tasks.

  • Perform an IISRESET on each server
  • Restart the AD FS service on AD FS server
  • Update Relying Party metadata
    1. Open AD FS 2.0
    2. Navigate to AD FS 2.0 > Trust Relationships > Relying Party Trusts
    3. Right click each relying party and select Update from Federation Metadata
    4. Click Update

Microsoft CRM 2013 or 2015 Event ID 1309 ADFS IFD Resolution

When attempting to login to an IFD deployment of CRM 2013 or 2015 you receive an event Error: 1309 looking like this:

Event code: 3005
Event message: An unhandled exception has occurred.
Event time: 7/01/2016 12:08:14 AM
Event time (UTC): 6/01/2016 1:08:14 PM
Event ID: 0daeff15a8f24e939623db80c40522d5
Event sequence: 3
Event occurrence: 2
Event detail code: 0

Application information:
Application domain: /LM/W3SVC/2/ROOT-1-130965592186041416
Trust level: Full
Application Virtual Path: /
Application Path: C:\Program Files\Microsoft Dynamics CRM\CRMWeb\
Machine name: VSERVER07

Process information:
Process ID: 2300
Process name: w3wp.exe
Account name: NT AUTHORITY\NETWORK SERVICE

Exception information:
Exception type: SecurityTokenException
Exception message: ID4175: The issuer of the security token was not recognized by the IssuerNameRegistry. To accept security tokens from this issuer, configure the IssuerNameRegistry to return a valid name for this issuer.
at Microsoft.IdentityModel.Tokens.Saml11.Saml11SecurityTokenHandler.CreateClaims(SamlSecurityToken samlSecurityToken)
at Microsoft.IdentityModel.Tokens.Saml11.Saml11SecurityTokenHandler.ValidateToken(SecurityToken token)
at Microsoft.IdentityModel.Tokens.SecurityTokenHandlerCollection.ValidateToken(SecurityToken token)
at Microsoft.IdentityModel.Web.TokenReceiver.AuthenticateToken(SecurityToken token, Boolean ensureBearerToken, String endpointUri)
at Microsoft.IdentityModel.Web.WSFederationAuthenticationModule.SignInWithResponseMessage(HttpRequest request)
at Microsoft.IdentityModel.Web.WSFederationAuthenticationModule.OnAuthenticateRequest(Object sender, EventArgs args)
at Microsoft.Crm.Authentication.Claims.CrmFederatedAuthenticationModule.OnAuthenticateRequest(Object sender, EventArgs args)
at System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

Request information:
Request URL: https://auth.iwebscrm.com:444/default.aspx
Request path: /default.aspx
User host address: 58.175.75.97
User:
Is authenticated: False
Authentication Type:
Thread account name: NT AUTHORITY\NETWORK SERVICE

Thread information:
Thread ID: 29
Thread account name: NT AUTHORITY\NETWORK SERVICE
Is impersonating: True
Stack trace: at Microsoft.IdentityModel.Tokens.Saml11.Saml11SecurityTokenHandler.CreateClaims(SamlSecurityToken samlSecurityToken)
at Microsoft.IdentityModel.Tokens.Saml11.Saml11SecurityTokenHandler.ValidateToken(SecurityToken token)
at Microsoft.IdentityModel.Tokens.SecurityTokenHandlerCollection.ValidateToken(SecurityToken token)
at Microsoft.IdentityModel.Web.TokenReceiver.AuthenticateToken(SecurityToken token, Boolean ensureBearerToken, String endpointUri)
at Microsoft.IdentityModel.Web.WSFederationAuthenticationModule.SignInWithResponseMessage(HttpRequest request)
at Microsoft.IdentityModel.Web.WSFederationAuthenticationModule.OnAuthenticateRequest(Object sender, EventArgs args)
at Microsoft.Crm.Authentication.Claims.CrmFederatedAuthenticationModule.OnAuthenticateRequest(Object sender, EventArgs args)
at System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

UPDATE

On later version of CRM like CRM 2016 SP1 and using ADFS 3. This error appeared differently. We blogged this here: http://www.interactivewebs.com/blog/index.php/crm/microsoft-crm-ifd-the-ssl-certificate-does-not-contain-all-upn-suffix-values-that-exist-in-the-enterprise-cannot-login/

The cause

This is likely happening after updating the ADFS Token Signing Certificates in an IFD deployment of Microsoft CRM Server. In our case we had recently updated the ADFS signing certificate using the PowerShell command:

Update-AdfsCertificate -CertificateType Token-Decrypting -Urgent
Update-AdfsCertificate -CertificateType Token-Signing -UrgentSet-ADFSProperties -AutoCertificateRollover $false 

After doing that we found that the IFD deployment would not allow login to the CRM server for external users, with the above error being logged.

The Fix

Microsoft Dynamics CRM error: The issuer of the security token was not recognized by the IssuerNameRegistry – Solved

“The issuer of the security token was not recognized by the IssuerNameRegistry. To accept security tokens from this issuer, configure the IssuerNameRegistry to return a valid name for this issuer.”
Or…

adfs1

If your Microsoft Dynamics CRM users are seeing the above errors when attempting to log-in, you may have an ADFS Certificate issue. ADFS generates new certificates about a month prior to certificate expiration, however, Dynamics CRM does not recognize them until you take a few steps to resolve the issue.

To locate your ADFS Certificates, navigate to the ADFS Console. Under “Service”, click on “Certificates”, where you will find a Primary and Secondary certificate. If the current date is close to the date of your Primary certificate “Effective Date”, it’s safe to assume that this is the underlying issue.

adfs2

To resolve this issue:

1. Navigate to the ADFS Console >> Trust Relationships >> Relying Party Trusts.
2. Right click on the trust and select “Update from Federation Metadata…”
a. If there are two trusts, do them both. This may be a case where you have one for Internal and External.

adfs3

3. Open Command Prompt. Be sure to right-click and “Run as Administrator”.
a. From within CMD, type “iisreset”.

adfs4

4. Open “Services” and restart the “ADFS” service.

adfs5

a. If ADFS does not start, be sure to check the “Windows Internal Database” service and make sure it is started, and then try restarting the ADFS service.

If these initial steps do not resolve your issue for any reason, continue with the following steps below:

5. Navigate to “CRM Deployment Manager”.
a. Run “Configure Claims-Based Authentication” wizard, upper right hand corner.
b. Click “Next” all the way through the wizard, nothing needs to be changed here.

adfs6

6. Run “Configure Internet Facing Deployment” wizard.
a. Click “Next” all the way through the wizard, nothing needs to be changed here either.

adfs7

7. Now, perform Steps 1-4 again as outlined above.
a. Update Federation Metadata
b. IISReset
c. Restart ADFS Service

Your users should be able to log-in to Dynamics CRM again. I hope you find this helpful and that it resolved your issue.

Moving Active Directory AD to a New Domain Controller DC

Since I don’t have to do this very often, but always seem to forget how to transfer the Schema Masterand Domain Naming Master, I decided to write it down, when it came up again as I transferred all the roles to my Windows 2012 server.

The following three FSMO roles can be migrated from Active Directory Users and Computers. Right mouse click on the domain and select Operations Masters. There is one tab for each of the three FSMO roles:

PDC
RID Pool Manager
Infrastructure Master

The following FSMO role can be transfered from Active Directory Domains and Trusts. Right mouse click on Active Directory Domains and Trusts, and select Operations Master.:

Domain Naming Master

For the Schema Master FSMO role, you first need to register a dll by executing the following command (Note: This only needs to be done once from an elevated command prompt.):

c:\> regsvr32 schmmgmt.dll

Then, you can add the Active Directory Schema Snap-In to a Microsoft Management Console (MMC). With the Snap-In added, ensure that the targeted domain controller is the one that you want to transfer the Schema Master role to. To change it, right mouse click on Active Directory Schema, under Console Root, and select Change Active Directory Domain Controller.. to select the domain controler you want to transfer the role to. Once that is done, right mouse click on Active Directory Schema, and select Operations Master to change the role.

If you do not have a different domain controller targeted, you will get the following message:

The current Active Directory Domain Controller is the Operations Master. To transfer the Operations Master to a different DC, you need to target Active Directory Schema to that DC.

And when you switch the target domain controller, you get the following, which is okay for what we want to do.:

Active Directory Schema snap-in is not connected to the schema operations master. You will not be able to permform any changes. Schema modification can only be made on the schema FSMO holder.

Fatal error: Cannot redeclare wpb_getImageBySize() (previously declared in plugins/js_composer/include/helpers/helpers.php

WPBakery Install Receives the Error: fatal error: Cannot redeclare wpb_getImageBySize() 

Fatal error: Cannot redeclare wpb_getImageBySize() (previously declared in /srv/www/vhosts/www.busybooks.com/wp-content/themes/busybooks/wpbakery/js_composer/composer/lib/helpers.php:15) in /srv/www/vhosts/www.website.com/wp-content/plugins/js_composer/include/helpers/helpers.phpon line 111

When installing the WPBakery plugin you receive the above error after trying to activate the plugin. 

The Fix

The issue is easily fixed by installing one of the default themes from WordPress. Activating it. Then returning to the plugins and activating the WPBakery Visual Composer.

DNN (dotnetnuke) Active Forum Module Control Panel a critical error has occurred

Error when opening the DNN Active Forum Module Control Panel

When you attempt to open the forum module Control Panel, you receive a.net load error that says a critical error has occurred. Upon looking at the log files for the website within DNN, you’ll notice that the related error message looks something like this.

bsoluteURL:/Default.aspx
DefaultDataProvider:DotNetNuke.Data.SqlDataProvider, DotNetNuke
ExceptionGUID:1012073d-d31d-4a73-a051-31478c9de05d
AssemblyVersion:7.4.0
PortalId:0
UserId:3429
TabId:107
RawUrl:/Resources/Forum/ctl/EDIT/mid/506
Referrer:http://website.com.au/Resources/Forum
UserAgent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/600.6.3 (KHTML, like Gecko) Version/8.0.6 Safari/600.6.3
ExceptionHash:eUa1nHF8hNveOCQzqX0zOg==
Message:Object reference not set to an instance of an object.
StackTrace:
InnerMessage:Object reference not set to an instance of an object.
InnerStackTrace:
at DotNetNuke.Modules.ActiveForums.Controls.Callback.OnLoad(EventArgs e)
at System.Web.UI.Control.LoadRecursive()
at System.Web.UI.Control.LoadRecursive()
at System.Web.UI.Control.LoadRecursive()
at System.Web.UI.Control.LoadRecursive()
at System.Web.UI.Control.LoadRecursive()
at System.Web.UI.Control.LoadRecursive()
at System.Web.UI.Control.LoadRecursive()
at System.Web.UI.Control.LoadRecursive()
at System.Web.UI.Control.LoadRecursive()
at System.Web.UI.Control.LoadRecursive()
at System.Web.UI.Control.LoadRecursive()
at System.Web.UI.Control.LoadRecursive()
at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
Source:
FileName:
FileLineNumber:0
FileColumnNumber:0
Method:
Server Name: SERVERNAME

 

The Fix

It is good practice to ensure that you have the latest version of the DotNetNuke forum module on your website. Especially if you are using the later versions of DNN.  Currently the module project has been moved into an open source project on GitHub. The latest version can be found here: https://github.com/ActiveForums/ActiveForums

 

 fixing the error

 you need to ensure that the web.config file also includes the following reference.

        <section name=”cryptography” requirePermission=”false” type=”DotNetNuke.Framework.Providers.ProviderConfigurationHandler, DotNetNuke” />

 

 

    <cryptography defaultProvider=”CoreCryptographyProvider”>

      <providers>

        <clear />

        <add name=”CoreCryptographyProvider” type=”DotNetNuke.Services.Cryptography.CoreCryptographyProvider, DotNetNuke” providerPath=”~\Providers\CryptographyProviders\CoreCryptographyProvider\” />

      </providers>

    </cryptography>


 Take note of where this is found in the web can feed file below.

Screenshot 2015 06 27 17 13 53

 

 

Google Analytics API Access V3

Accessing your Google Analytic Data via API

To allow a third party module or application to view and display your Google Analytics data for your website. You need to get a few things organised.

1. You need to have a Google Analytic account with your website registered.

Go to: http://www.google.com/analytics/   and follow their instructions to set up your URL under an account that you can manage and access with Admin permissions. We are not going to go through these steps here as it is a given that you will have this. Seek help from Google if you can’t manage.

 

2. Set up an API for your Google Analytics Account at the Google Developers Portal.

Go to: https://developers.google.com/  and login with your account.

To get started using Google Analytics API, you need to first create or select a project in the Google Developers Console and enable the API. Using this link guides you through the process and activates the Google Analytics API automatically.

Alternatively, you can activate the Google Analytics API yourself in the Developers Console by doing the following:

  1. Go to the Google Developers Console.
  2. Select a project, or create a new one.
  3. In the sidebar on the left, expand APIs & auth. Next, click APIs. Select the Enabled APIs link in the API section to see a list of all your enabled APIs. Make sure that the Google Analytics API is on the list of enabled APIs. If you have not enabled it, select the API from the list of APIs, then select the Enable API button for the API.
     Screenshot 2015 07 07 00 53 20
  4. In the sidebar on the left, select Credentials.
     Screenshot 2015 07 07 00 54 06

In either case, you end up on the Credentials page and can create your project’s credentials from here.

Create a client ID

From the Credentials page, click Create new Client ID under the OAuth heading to create your OAuth 2.0 credentials.

  1. For the APPLICATION TYPE select Service account.
  2. Click Create Client ID.
  3. For the KEY TYPE select P12 key. (The system will download a .P12 file. You will need this file to upload to the module)
  4. A dialog box appears. To proceed, click Okay, got it.

 

3. Add service account to Google Analytics account

The newly created service account will have an email address, <projectId>-<uniqueId>@developer.gserviceaccount.com; Use this email address to add a user to the Google analytics account you want to access via the API. For this tutorial only Read & Analyzepermissions are needed.

Select User Management (in the Analytics Admin)

Screenshot 2015 07 07 00 49 39

Enter the weird email address from the API credentials step above to give Read & Analyze permissions.

Screenshot 2015 07 07 00 51 16

 

In Summary

  1. You have created a Google Developer Account.
  2. Created an API and Given Permission to “Analytics API”
  3. You have Downloaded a P12 Credentials file.
  4. You have Authorised the associated weird google email address from the P12 account to have read permissions on your Analytics Account.

If you get all that right, then the module we use, will work to access your Google Analytics data from within your module.