The trust relationship between this workstation and the primary domain failed Windows 2012 R2 Hyper-V snapshot

The trust relationship between this workstation and the primary domain failed Windows 2012 R2 Hyper-V

Screenshot 2014 08 02 23 22 38

After working with Hyper-V and Snap shots, you may find that a previously working domain member machine gets this error message. This is because the Domain Controller will automatically update passwords of Machine Accounts every 30 days, and a restored snapshot may not match the new pass.

The solution

  1. On the effected client machine open PowerShell
  2. Run the following command “Reset-ComputerMachinePassword” or specify the credentials switch if the account your running PowerShell with doesn’t have the correct AD perms for the CMDlet “Reset-ComputerMachinePassword –credential Domain\Adaccount” (You will be prompted for the domain password).
  3. After running this give the client machine a restart

After Reboot, the server will function correctly.

CRM 2013 IFD An error occurred An error occurred. Contact your administrator for more information.

CRM 2013 IFD An error occurred An error occurred. Contact your administrator for more information. 

When trying to setup up IFD with CRM 2013, we kept getting the error:

An error occurred. Contact your administrator for more information.          

  • Activity ID: 00000000-0000-0000-0300-0080030000ed
  • Relying party: CRM IFD Relying Party
  • Error time: Sat, 02 Aug 2014 08:32:56 GMT

 

Little or no additional information in the Event Log:

We had attempted to setup IFD with ADFS 3.0 and at the time there was very little additional information available for this setup. The MSDN blog that we followed was good, but for ADFS 2.1.

The Solution.

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.

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:555 as the network address.

Screenshot 2014 07 10 17 58 12

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/

 

How do I list my business into the white pages listings – should I pay for a white pages business listing

WhitePagesBusinessListing

How do I list my business into the white pages listings?  

Should I pay for a white pages business listing?

Recently we were asked by one of our clients, if they should renew their white pages business listing in the Australian white pages. To help them make this assessment they asked us to review what sort of contact they were receiving from the white pages listings with regard to click through to their website. The results were very interesting!

Using the Google analytics that we had placed on the website, we were able to ascertain that there were some  24,000 referring sites that were bringing customers from external links into their existing website in the past year. Of these 24,000 only three of them had come from the white pages listing.

We then decided to check what ranking their particular listing was getting for their primary keywords. In other words if somebody types in a business name into Google, were they receiving the white pages listing any way relevant? The answer was clearly no. On checking Google, Yahoo, Bing, the primary keywords were not to be found within the first 100 listings on any of those returns.

The conclusion here is that the white pages listing was bringing absolutely no relevant web traffic to their site.

So what benefit is a  You are year is no wall you you you you are you in those little bit pages listing?

For this particular business there was very little web related benefit whatsoever. As it turned out the additional cost they were paying for a professional business listing was giving them web related benefits who actually bringing no benefits at all.

The white pages business listing, as a paid service included some additional features such as a map of where to find this business. This business in particular has no walk-in traffic. So using a map in a paid listing is of no benefit at all.

The question could then be asked, isn’t it important to be able to be found within the white pages? And the answer is clearly yes, but luckily the white pages allow you to list your business and phone number free of charge. This means that the fuse Luddites remaining in this world who would dial directory assistance to receive a phone number would still receive the correct phone number for the business free of charge.

How do I list my business in the white pages listings for free?

It is really simple:  Google “whitepages”  and go to the primary website. From there you will be able to sign up for free and list your business. If you have trouble doing this you can even phone them on 1800 810211. 

How do I work it out if my business requires a paid business listing as per the example above?

You can simply contact us using the email contact form here:http://www.interactivewebs.com/ContactUs.aspx  we will be happy to help you free of charge to understand if your business could benefit from a paid white pages listing.

Microsoft CRM 2011 Exception message: ID4175: The issuer of the security token was not recognized by the IssuerNameRegistry

Error

When attempting to login to an IFD (Internet Facing Deployment of CRM) you receive this error:

Event code: 3005 Event message: An unhandled exception has occurred. Event time: 10/06/2014 1:54:52 AM Event time (UTC): 9/06/2014 3:54:52 PM Event ID: 6da606a9a6794c2a8f504cc6b8b3be3e Event sequence: 2 Event occurrence: 1 Event detail code: 0  Application information:     Application domain: /LM/W3SVC/2/ROOT-1-130468028783689054     Trust level: Full     Application Virtual Path: /     Application Path: C:\Program Files\Microsoft Dynamics CRM\CRMWeb\     Machine name: VSERVER08  Process information:     Process ID: 1540     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.interactivewebs.com:444/default.aspx     Request path: /default.aspx     User host address: 101.164.212.248     User:      Is authenticated: False     Authentication Type:      Thread account name: NT AUTHORITY\NETWORK SERVICE  Thread information:     Thread ID: 8     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)  Custom event details: 

The Problem

For unidentified problems, the ADFS authentication is failing and needs to be reset.

Solution:

Run the Deployment Manager with same certificate

These instructions are the last part of the instructions we have created for updating an out of date SSL certificate used in an IFD deployment. Basically we are following the same instructions, but skipping the step of replacing with a new SSL certificate. We are just running the deployment again against the same certificate. 

1. Run the CRM deployment manager:

image

2. Run the Configure Claims-based Authentication

image

Select the default settings.

image

image

Which should be the default from your IFD setup

But when you get to the Certificate, you need to select the new certificate.

image

image

Which should be visible from the list after importing it in the steps above.

3. Run the Configure Internet Facing Deployment action and just step though it with the default settings.

image

4. Restart the AD FS 2.0 Windows Service

image

Configure AD

Set the Service Communication Certificate

1. Start AD FS 2.0 Management

image

2. Expand certificates and select Set Service Communications Certificate

image

3. Select the new certificate that will be listed here.

image

Update Relying Party Trusts

1. From the AD FS 2.0 Management, Select your replying party trusts and update from the federation metadata one by one.

image

Update both listed. They will likely have a red cross before you do this.

Restart Services

Restart AD FS Service:

image

and restart IIS the usual way.

And you should be done. Login to your CRM IFD again and enjoy.

 

DotNetNuke FileHelpers, Version=2.0.0.0, Culture=neutral, PublicKeyToken=3e0c08d59cc3d657′

After Upgrading DNN 7 and browsing to the ADMIN>Site Settings you find an error: A critical error has occurred. Object reference not set to an instance of an object.

FileHelpers, Version=2.0.0.0, Culture=neutral, PublicKeyToken=3e0c08d59cc3d657′

DNN file Helpers.dll

Error: File Management is currently unavailable. DotNetNuke.Services.Exceptions.ModuleLoadException: (0): error CS1705: Assembly ‘DotNetNuke.Modules.DigitalAssets, Version=7.1.1.385, Culture=neutral, PublicKeyToken=null’ uses ‘Telerik.Web.UI, Version=2013.2.611.40, Culture=neutral, PublicKeyToken=121fae78165ba3d4’ which has a higher version than referenced assembly ‘Telerik.Web.UI, Version=2013.1.403.40, Culture=neutral, PublicKeyToken=121fae78165ba3d4’ —> System.Web.HttpCompileException: (0): error CS1705: Assembly ‘DotNetNuke.Modules.DigitalAssets, Version=7.1.1.385, Culture=neutral, PublicKeyToken=null’ uses ‘Telerik.Web.UI, Version=2013.2.611.40, Culture=neutral, PublicKeyToken=121fae78165ba3d4’ which has a higher version than referenced assembly ‘Telerik.Web.UI, Version=2013.1.403.40, Culture=neutral, PublicKeyToken=121fae78165ba3d4’ at System.Web.Compilation.AssemblyBuilder.Compile() at System.Web.Compilation.BuildProvidersCompiler.PerformBuild() at System.Web.Compilation.BuildManager.CompileWebFile(VirtualPath virtualPath) at System.Web.Compilation.BuildManager.GetVPathBuildResultInternal(VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile, Boolean throwIfNotFound, Boolean ensureIsUpToDate) at System.Web.Compilation.BuildManager.GetVPathBuildResultWithNoAssert(HttpContext context, VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile, Boolean throwIfNotFound, Boolean ensureIsUpToDate) at System.Web.Compilation.BuildManager.GetVPathBuildResult(HttpContext context, VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile, Boolean ensureIsUpToDate) at System.Web.UI.TemplateControl.LoadControl(VirtualPath virtualPath) at DotNetNuke.UI.Modules.WebFormsModuleControlFactory.CreateModuleControl(TemplateControl containerControl, ModuleInfo moduleConfiguration) at DotNetNuke.UI.Modules.ModuleControlFactory.LoadModuleControl(TemplateControl containerControl, ModuleInfo moduleConfiguration) at DotNetNuke.UI.Modules.ModuleHost.LoadModuleControl() — End of inner exception stack trace —

The problem

The problem relates to a missing file that can be updated to the website /bin folder. The file is part of a free library that can be found here: http://sourceforge.net/projects/filehelpers/files/File%20Helpers%20Downloads/Version%202.0.0/

The file you need is: FileHelpers.dll  front he 2.0 release from way back in 2010.

The Fix

Download the file directly here: https://www.dropbox.com/s/otusnlf1jmy9f6o/FileHelpers.dll?dl=0

Extract it into the /bin folder.

And save that to the /BIN folder in your DNN website, this will fix the issue and leave any third party modules that reference it working. File Helpers DLL in DNN

DotNetNuke DNN Spam Registrations Problem Fixed

DotNetNuke DNN Sites getting spam registrations – How to stop them

In recent weeks, many of our DNN websites have systematically been targeted for Spam New User Registrations. There has been some discussion around the how and why, and as much as we can tell, the problem is this:

1. Some script kiddy has bothered to write a bot that finds DNN websites. It is not even a good bot, because it is not capable of validating registrations to automated active email addresses. (If you are the creator of the bot… “YOU ARE DOING IT WRONG” as it is not going to bring the Google results you are looking for.)

2. The bot will attempt access to:  www.yoursite.com /?ctl=Register
?ctl=Register

3. This brings into play the default DNN registration process module.

4. This page is currently available if your site has either Public or Verified registrations enabled.

5. Tricks on derating the bot by raising the password complexity appeared to work a short time only.

6. Enabling the inbuilt Captcha is as good as useless, as almost any OCR application can break it.

7. A better simple solution is needed.

 

ReCaptcha is the FIX that is working well

Here at InteractiveWebs, we decided that we would enable Recapcha (a cleaver Google Initiative https://www.google.com/recaptcha/ ) that is harder to be machine broken, and test the results. We found that all the spam registrations stopped once Recaptcha was used.

To do this we created two Free DNN Modules to add Recaptcha to the URL that this bot is using to register on sites. The two modules are to support DNN 6.2 +  and 7x +.

The modules replace the standard captcha control to a recaptcha

From this:

DNNCaptcha

To this:

DNN Spam Registration Stop

This is a good link explaining how Recaptcha came into existence, and why it works well: https://www.youtube.com/watch?v=cQl6jUjFjp4

The Free Solution and Installing iWebs Regsiter

The free modules are available of download here: http://www.interactivewebs.com/DotNetNukeModules/ModuleDownloads.aspx

To install them and fix your site you will need to follow the instructions below:

Step 1 – Register your site for Recaptcah

Go to: https://www.google.com/recaptcha/intro/index.html  and register your domain, or domains. This will give you the ability to use recaptcha on your DNN sites on any domain you like.

DN Google Recaptcha

Step 2 – Copy the Public Key and Private Key for your Domain

You are going to need they keys that this site provides:

DNN Recaptcha Keys

Similar to these.

 

Step 3 – For you DNN site, Turn on the DNN Captcha system.

ADMIN>>SITE SETTINGS>> USER ACCOUNT SETTINGS>>  “Use CAPTCHA for registration” Ticked.

DNN Enable Captcha

Step 4 – Download and Install iWebs – Register

Install our “iwebs- register” module, making sure you pick the one that is for your DNN version.

  • DNN 6.2 And laters: iWebsRegister 62.6.3.0 PA.zip (at time of writing this)
  • DNN 7 and later:  iWebsRegister 72.7.1.0 PA.zip (at time of writing this)

Once installed, you need to add the module to a page as you would any other. We recommend adding it to it’s own page in the DNN Admin menu, and keeping the page Admin Only.

DNN Recaptcha Module Downlaod DNN Recaptcha Module

Step 5 – Configure the iWebs Register Module.

The module you are looking for is called: iWeb’s – Register – You can select the Settings from the module drop down as you would any other DNN module.

DNN Module Settings

 

Enter the Public Key and Private Keu information that you received from your Google Recaptcha registration of your domain. THEN SELECT UPDATE to save the information.

DNN Captcha Settings

Step 6 – Install the Register Control

After saving your public and private keys by clicking “update” you are ready to:

Click on the “Install Register Control”

This will inject the recaptcha setting into your website. So when you hit any registration URL (www.yoursite.com /?ctl=Register) you now get the recaptcah box.

Update to V2 of Recaptcha

Google has released what they call V2 of Recaptcha. We have update the module to support this. The process of updating to V2 goes like this.

1. By default, previously created recaptcha keys are V1. Any updated installs of our module will need to be put into V1 mode (in the settings) to keep working with your V1 keys that you have previously configured into the module. So after updating our module to the latest release, go into the module settings and enable V1 mode for the module to keep working.

2. V2 recaptcha is better than V1. So we would suggest that all users of the module update to V2. To do this, you update our module to the latest release, then go into the Google Recaptcha management page, and delete your domains security keys, then generate new keys for V2. They have instructions on that process, all be is hard to understand.

Once you have new V2 recaptcha keys, you update these new keys back into our module and ensure that the V1 mode is NOT enabled. The V2 recaptcha will then run on your site.

To Remove and Uninstall

Step 1. From the iwebs – Register module settings, click the “Restore Register Control”

DNN Remove Recaptcha

2. Uninstall the iwebs – Register module as you would any other DNN module.

 

Thoughts

This was a quick solution to some script kiddies attempt to attack DNN. I’m actually struggling to find the purpose (if you wrote the bot and you are reading this, I would love to hear why).  There is little threat by the registrations that I can find. More annoying that anything else. While Recaptcah can be broken, it would take some smarts or costs to use online services for the bot, so I suspect they will not bother and recaptcha will reign for this problem. In any case, if they spend some time and effort making the bot work for recaptcah, it is easy enough for us to implement some of the loads of other solutions available to stop them.

Donations

We included a donation button. If you find the solution, blog, research we did, modules we created and responses we provide to be helpful. Please consider throwing us a few $

Mac Pro 2013 Multiple Displays Stop Working with OS X 10.9.3 – Fixed

Hot to Fix Multiple Monitors not working in OS X 10.9.3OS X 10.9.3 Mltiple Monitor Problems

Mac Pro 2013 computer users have experienced problems in some configurations since upgrading to Mavericks OS X 10.9.3. For most people, the issue related to the use of mini port to DVI external monitors.

The mac pro by design can only run two Miniport to DVI monitors, and any additional monitors need to be run on a converter that has additional power. Apple call this their Dual Link DVI adapter. Essentially this is the same thing, just with a powered USB port on it. If you were to try an run 3 mini port to DVI adapters, what you would find is that only two monitors plugged in would run. Effectively the last two plugged in in any combination would be the two that ran.

Apparently this is by design, and part of the way that the Mac Pro is set to provide a stable and powerful signal in the miniprot to DVI adapters. The additional power that is required is subsequently provided by the Dual Link (USB port).

The problems OS X 10.9.3

With this update, only two monitors would work, were previously more would run fine. Many online communities were talking about this problems that is considered serious for IT professionals. Here at InteractiveWebs.com we identified the problem, and lodged a support ticket with Apple. We had some back and forth providing the photo’s of our configurations, and some software tools that they provided to give system feedback.

The Fix for Multiple Display Problems OS X 10.9.3 – is 10.9.4

Today we received a final version of OS X 10.9.4, and to our joy it has restored the monitor problems that we experienced and things are back and firing as they should.

Comments

I have seen some people digging in for a sledging of Apple over this issue. Personally I am old enough to have experienced this type of serious issue with other more prevalent operating system. In those instances, the disconnect between manufacturer, OS developers and software developers meant that we sometimes never fixed display problems. I can remember one instance with a Matrox graphic card that we paid something like $1200 for, and never could get it working as designed due to operating system changes and software incompatibilities. We later found the same cards on sale for $50 after we had dropped $6 K into the cards. 

It was problems like that that, and the fact that no matter who we told our problems to (MS, Matrox, or 3rd party software developers) that we could never get a fix. No one would own the problem. That is exactly the reason we changed to “Apple Fan Boys” and although we have spent 10 days with less than optimal Mac Pro systems, it still remains that we had a problem. Told Apple, and they fixed the darn thing in a timely manner. Well done I say!

Mars Edit can’t upload images to WordPress on IIS

MarsEditIcon 

Having Troubles Uploading images to WordPress hosted on IIS

If you are like me and enjoy a Mac, and WordPress, then you have probably discovered MarsEdit. We were experiencing problems uploading images to our WordPress blog.

Upload File Error
Can’t do upload file for “blog name” because the server reported an error. The server returned an unexpected response code: 413.

WordPress Upload File Permissions on IIS

You upload an image in WordPress and either you get an error or the image will upload, thumbnails would work but the actual image would not have read permissions.

If you can’t upload an image at all, it’s probably because you need to give the IUSR account Read/Write/Modify permission on your wp-content folder.  This will allow you to upload, and do the WordPress & plugin updates.

IIS WordPress File Upload Permissions

Alos, you may you need to do is give the IIS_IUSRS group Read permissions on your “C:\Windows\Temp” folder.

Make sure to notice that the two permission changes you make are not for the same user/group.   Give IUSR permissions on your wp-content folder and IIS_IUSRS permissions on your Windows temp folder.

Note: If you have edited your php.ini file and change the upload temp directory then you will need to give IIS_IUSRS group read permissions on that folder instead.

IISWordPressIIS_USERS

That should be about all that is required to fix the issue in IIS.