locked
AD FS interfacing with CRM RRS feed

  • Question

  • Hi

    I have been trying to deploy ADFS on my server, it required a default website, I did not have a default website in IIS7, SBS2008 so I created one.

    I still could not get ADFS to work and thought there may now be a problem with CRM2011. So I repaired the installation. This has now created a new CRM website and taken over the default website, so now I have a crm website and a crm1 website.

    Neither of these now work

    Any suggestions on what to do next please?

    Thank you

    Best regards

    Mark

    Monday, April 18, 2011 7:07 PM

Answers

  • Hi Steve

    Thanks for your reply. We eventually got CRM 2011 running with Claims based & IFD on the same server. We installed ADFS on 443 (seems to be happy enough despite the competition!), and then CRM on 420 (initially we had problems there, but then enabled access via Windows Firewall & our router). It's a pain having to attach :420 onto the web address, but at least that side of things is now working OK.

    Just struggling to get the email router working now. We are using exchange 2010, which from what I understand doesn't use a functionality called WebDav (which I believe the router requires), but instead uses Exchange Web Services. Tried all sorts so far, but no joy yet! We'll get there eventually! Any suggestions?!

    Why can't Microsoft make things easy?!

    Thanks again

    Julian

    Monday, June 6, 2011 12:27 PM

All replies

  • I saw a good video on this posted on Jim Glass's blog, it is buy the IFD team at Microsoft in response to a lot of other people having issues.

    http://blogs.msdn.com/b/jim_glass/archive/2011/04/06/introducing-microsoft-dynamics-crm-2011-claims-based-authentication.aspx

     


    Jamie Miley
    http://mileyja.blogspot.com
    Linked-In Profile
    Follow Me on Twitter!
    Monday, April 18, 2011 7:38 PM
    Moderator
  • I've watched the video! Hasn't helped. Basically, we ran the upgrade of CRM 2011, then tried installing ADFS. However, there was no default web site, so we had to install a new default site. So far, so good.

    We then installed ADFS, set up claims based authentication on CRM, set up ADFS, tested the setup and all working.

    We then tried setting up IFD on CRM, only to find that the Discovery Web Service could not be found. We then ran repair from CRM setup. All ok, until we found that CRM had taken over the default web site, to leave us with two CRM sites - Microsoft Dynamics CRM and Microsoft Dynamics CRM_1. Neither of which worked, the first showing the CRM site on http, but with no data.

    Uninstalled and reinstalled ADFS, set it up, metadata pages displaying ok, rekeyed our godaddy wildcard certificate. End up with "403 - Forbidden: Access is denied" on ie when attempting to access by https://crm.domain. When accessing via https://auth.domain. we get certificate error messages.

    Can anyone help with the following:

    (1) I seemed to remember that when I originally installed CRM / ADFS, there were a few lines I had to add to the wildcard certificate. Is this right, and if so what were they? (Not "manage private keys").

    (2) Which CRM site should I use? If the one where there is currently no data, how do I "re-attach" the data?

    (3) Even though the wildcard certificate is valid and has been rekeyed, why am I getting certificate error messages? (Sites updated with rekeyed certificate, as has ADFS & CRM; intermediate certificate installed)

    (4) When connecting to the CRM site through IIS7, via https port 444, we get "there is a problem with this websites security certificate", then when we continue, HTTP error 404.0 - the resource has been removed. Physical path c:\Program Files\Windows Small Business Server\Bin\WebApp\SBS Web Applications\adfs\Is\. Sure enough, the \adfs\Is part does not exist on the web server

     

    Can anyone help?

    Monday, April 18, 2011 11:32 PM
  • Hi,

    I would assume that when CRM was first installed, it was installed to the default web site? It might be that during repair, the repair tried to take over the default web site again which might leave two CRM sites?

    In this case it might be best to start with a clean machine/OS and do reinstalls. Certainly a more invasive procedure but it might ensure a lot cleaner deployment. Here is what I might try (no guarantees that this is the best way to solve your problem but it should get the job done):

    1. Backup your organization database(s).
    2. Reinstall the OS. (Another option might be to just uninstall ADFS 2.0 and CRM. Then uninstall the IIS role and then reinstall it.)
    3. With a clean machine and IIS (only website that exists is the default site), install ADFS 2.0 first.
    4. Delete any existing MSCRM_CONFIG database on your SQL server instance so that you can start with a fresh deployment.
    5. Install CRM server and have CRM create a new deployment. During CRM install, have CRM create a new website to use.
    6. After install, import your existing org db(s) into CRM using the Deployment Manager.
    7. Verify that you can access your orgs over HTTP.
    8. Use IIS to add an HTTPS binding to your CRM web site.
    9. Configure Deployment Manager web address settings to use the new HTTPS binding.
    10. Verify that you can access your orgs over HTTPS.
    11. Next configure ADFS 2.0 as the Federation Service. Verify you can access the ADFS 2.0 federation metadata. (It would be okay to do this prior to installing CRM of course.)
    12. Next configure claims and IFD for CRM. Verify that you can access the CRM federation metadata.
    13. Configure relying party and claims rules in ADFS 2.0 for your CRM deployment.
    14. Verify that you can log into CRM over IFD.

    For more details on steps 11 through 14, please check out the Claims-based Authentication white paper.

    Let us know if this helps.

    Thanks,
    Michael

    Friday, May 6, 2011 8:56 PM
  • Hi Michael.

    Thanks for your reply. The boss was actually wanting to upgrade the OS, so what we have done is to put the HDD with SBS 2008 to one side and installed a new HDD with SBS 2011 Standard and SQL 2008 R2. Can't get much fresher than that!

    I will certainly follow your instructions above. One query, though. We obviously have the database files on the HDD that we set aside, and we can connect up to that disc when it come to importing them using Deployment Manager, However, during the fresh install, we renamed the server (we only have one, and renamed it to something simpler!). Is that likely to cause any problems importing the databases? If so, do you know of a workaround?

    Hopefully, with your instructions above, we'll be able to crack this. First of all, though, I need to sort out issues with wildcard certificates and outlook certificate errors connecting to Exchange 2010. Why can't Microsoft make life simple :-)

    Thanks once again for your help.

    Julian

    Monday, May 9, 2011 7:07 PM
  • Hi,

    Renaming the server shouldn't cause any problems since you will be importing the organizations into a new deployment and during the org import, we'll create new SQL connection strings for the org.

    In your case, this is what I expect that you will do:

    1. Run server setup on your new SBS2011 OS.
    2. During server install, select the option to "Create new deployment" and point setup to your SQL 2008 R2 instance on your clean OS.
    3. Setup will run and create a new MSCRM_CONFIG database and the first organization db. (You might not need this first org db, so you can always delete it later.)
    4. After setup is complete, you'll want to import your org databases from your SBS2008 drive.
    5. First take backups of your org dbs as .bak files.
    6. Then restore the .bak db files into your new SQL Server 2008 R2 instance.
    7. Once those dbs are restored, go to Deployment Manager and select the Import Organization wizard.
    8. On the first page of the wizard, select your SQL Server 2008 R2 instance and the organization database that you restored. Complete the wizard and let the import happen.
    9. After the import is complete, verify that the import was successful by trying to access the org through the web application.
    10. Now just go through the process to configure your deployment for claims and IFD.

    Hope this helps.

    Thanks,
    Michael

    Wednesday, May 11, 2011 8:52 PM
  • Hi Michael

    Your last post was a great help. We've successfully installed CRM & imported the old data. All is viewable via http://crm.ourdomain.co.uk:5555 and all working ok.

    So, after a few days making sure all was well, I thought I'd move on to configuring claims, using the video at http://www.youtube.com/watch?v=ZD5qaa-G99E (Introducing Microsoft Dynamics CRM 2011 Claims-based Authentication).

    All went well - the metadata file for adfs worked, I configured Claims Based Authentication, I tested the metadata using the address at the end of the log file, and all worked OK. However, when I enter the address for the crm site into IE, it brings up the IIS7 page for the default web site.

    Now, the settings for the http crm address in Deployment Manager / properties was the default one of SMARTAHQ:5555. As mentioned previously, we were able to access the crm site using http://crm.ourdomain.co.uk:5555 without any problem.

    When I added the https binding to the CRM site in IIS, I gave it a port of 442 (since the Default site was using 443) & attached it to our wildcard certificate.

    In the CRM / properties address page for https I put the address of crm.ourdomain.co.uk.

    As mentioned above, all worked well until I finished the claims setup and I tried running the site.

    I tried making a few changes. In the Deployment Manager, I adjusted the address to crm.ourdomain.co.uk:442. I then ran the claims setup again. the ADFS metadata came up, but when I ran the metadata address form the end of the log file, it came up with "Internet Explorer cannot display the page".  I tried changing the port to 444 in IIS, then Deployment Manager, then ran claims setup again, but with the same result.

    Have you any idea how to fix this? Should I have just left the https port as the default of 443?

    Thanks for your time.

    Julian

    Sunday, May 22, 2011 4:50 PM
  • Michael - I should have mentioned that ports 442 & 444 are open

    Julian

    Sunday, May 22, 2011 4:51 PM
  • Hi

    Further to my last post, just to reiterate that we have one server running SBS 2011 Standard. We are attempting to install CRM 2011 and ADFS2 on this one server, with the intention of setting up CRM Claims Based Authentication & Internet Facing Deployment (most of the users will be accessing remotely).

    The default web site has the following installed on it:

    adfs; autodiscover; ecp; ews; MS Server Active sync; owa; powershell; remote; rpc; rpc with cert; web help. It also has the following https bindings: https port 443 IP address 127.0.0.1; https port 443 IP address *; https port 444 127.0.0.1; https port 444 IP address *. All the above settings on the default site were installing by default, with the exception of the ports 444 which I changed from 443 in previous attempts to get CRM & ADFS 2 working.

    When I have tried previously to changew the remaing binding with 443, Remote Web Access has fallen over. I have had to run the "Set up your IP address wizard" again to reinstate it, which then automatically sets up a binding with port 443.

    I recently tried uninstalling / reinstalling adfs, changing the adfs port to 444, and crm to 443, only to find that the crm site would not start because 443 is in use by the default site. As mentioned in the post, I have tried leaving ADFS on port 443, and changing the port for CRM - and putting crm.ourdomain.co.uk:portnumber in the address, only to get "Internet Explorer cannot display the page".

    This is getting very frustrating!

    Can anyone help?

    Thanks

    Julian


    Thursday, May 26, 2011 5:43 PM
  • Hi Julian.

    We have had exactly the same problems.  Unfortunately, SBS hi-jacks the default secure website port (443) and depolys its own self-signed cert (or your purchased cert if you have one) for remote access.  This makes it very difficult to get AD FS running properly.  The CRM website can go pretty much anywhere as you can provide the port at log-on time. The AD FS is much more stubborn.  I expect it can be done but in the end we've bought a second server (an HP microserver as they were running a huge cash-back deal!)  I now have SBS and SQL on my main server, holding the CRM database.  I will end up with ADFS on the default website on the new server with CRM also on there on a custom port.  These can both use the same wildcard *.mydomain.co.uk certificate.  There will be 2 sets of federation metadata to give internalcrm.mydomain.co.uk and externalcrm.mydomain.co.uk.  ADFS runs on sts.mydomain.co.uk so everything matches the wildcard.  All you then need to do is set up the relevant host records in your DNS.

    I had big problems installing CRM on the new server initially, because claims-based authentication was still turned on (which is held in the CRM config database).  Once I'd disabled that the install went ok.  I am still having big problems properly configuring CBA as CRM doesn't seem to deploy any federation metadata so there is no way to connect the relying party in AD FS.  My next step is to try a completely clean install as Michael suggested above - deleting (having backed up) all the CRM databases, building a new deployment, then reimporting the org data.  Hopefully this will get rid of any hang-ups left from the SBS install!!

    This has been the only way I could see of getting around the mess of SBS/ADFS/CRM all on one IIS server and fighting over default sites, ports and certificates.  If you can't afford to spash out on the extra hardware (although ours only cost about $300 and that is only half a day's consultancy when it had taken days fighting with SBS), then maybe you could run it on a virtual machine?

    Hope that helps,

    Steve C
    www.mfsolutions.co.uk

     

    Wednesday, June 1, 2011 9:00 AM
  • Hi Steve

    Thanks for your reply. We eventually got CRM 2011 running with Claims based & IFD on the same server. We installed ADFS on 443 (seems to be happy enough despite the competition!), and then CRM on 420 (initially we had problems there, but then enabled access via Windows Firewall & our router). It's a pain having to attach :420 onto the web address, but at least that side of things is now working OK.

    Just struggling to get the email router working now. We are using exchange 2010, which from what I understand doesn't use a functionality called WebDav (which I believe the router requires), but instead uses Exchange Web Services. Tried all sorts so far, but no joy yet! We'll get there eventually! Any suggestions?!

    Why can't Microsoft make things easy?!

    Thanks again

    Julian

    Monday, June 6, 2011 12:27 PM