tag:blogger.com,1999:blog-53368448060277140652024-03-12T19:42:27.043-04:00One Byte at a TimeTroubleshooting the Infrastructure and Technologies Supporting Microsoft Dynamics 365Gagehttp://www.blogger.com/profile/06440235801891990171noreply@blogger.comBlogger33125tag:blogger.com,1999:blog-5336844806027714065.post-59585175800277906202017-08-25T14:29:00.001-04:002017-08-25T15:14:47.902-04:00ADFS Cache IssuesFrom time-to-time, employees may leave a company but end up coming back. With all that comes user management, accounts, access, permissions, etc…. While that is all easy enough from an Active Directory Standpoint, this can cause some complications with access into CRM/Dynamics 365 when using ADFS for claims-based authentication. Particularly if the user’s original AD account was deleted and then recreated with the same username.<br />
<br />
After the account is recreated, you may learn that there isn’t any issue re-enabling the user in CRM or Dynamics 365 but that the user cannot login via ADFS. There is also a similar scenario when companies migrate domains and keep the same user names, only changing the domain. Some behavior you may notice are 404 errors, wrong username showing in event viewer logs, and general ADFS errors. While I haven’t been able to pinpoint why this happens sometimes and not others, what I do know is the problem lies within ADFS.<br />
<br />
Basically what seems to be going on is the ADFS server has a cache of information already built up about the users, including GUIDs, SIDs, UPNs, etc… So when an authentication request comes through it checks for the username in its cache along with any associated records and matches what it can rather than pulling from Active Directory. When it does this it can pull the information from the old, previously-deleted account and then error out.<br />
<br />
Anyways, without further ado – here are two methods that I’ve used successfully to get through these situations. Sometimes one works and sometimes the other works – just some more mystery around this situation…<br />
<u><br /></u>
<u><b>Method 1: Disable the LSA Cache</b></u><br />
This method involves disabling the LSA cache by setting it’s maximum size to 0 – essentially making it nonexistent.<br />
<br />
<ol>
<li>Log on to the ADFS Server.</li>
<li>Open Registry Editor.</li>
<li>Go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa.</li>
<li>Create a new DWORD value in Lsa named LsaLookupCacheMaxSize and set the value to 0.</li>
<li>Close Registry Editor.</li>
<li>Have problem user try to log in again.</li>
</ol>
<br />
Whether or not this works, go back in after testing and delete the value you just created. ADFS may suffer from performance issues if it is left in place for a long period of time.<br />
<br />
<u><b>Method 2: Use PSTools to update SID</b></u><br />
Going this route requires the download of PsTools – a command-line tool that helps with server administration. In our scenario, it is the PsGetSid command that will be useful as it will force update the SID of the account held in cache from AD.<br />
<br />
<ol>
<li>Log on to the ADFS server.</li>
<li>Download PSTools from https://docs.microsoft.com/en-us/sysinternals/downloads/psgetsid.</li>
<li>Extract out the contents of the zip file into an accessible directory.</li>
<li>Run PSGetSid from command prompt using the following syntax: C:\{Directory}\PsGetsid.exe domain\crmuser</li>
<li>Have problem user try to log in again.</li>
</ol>
<br />
If neither of those methods works, there may be something else wrong. I would start by verifying that all other users can access CRM/D365 without issue and go from there. My apologies for not having exact error messages or screenshots on this post – it was just an issue I’ve run into in the past a few times and thought it may help someone out regardless as I’ve realized there isn’t much information out there about it.Gagehttp://www.blogger.com/profile/06440235801891990171noreply@blogger.com0Gainesville, FL, USA29.6516344 -82.32482619999996129.4309209 -82.647549699999956 29.872347899999998 -82.002102699999966tag:blogger.com,1999:blog-5336844806027714065.post-86373142402922418372017-08-09T17:26:00.001-04:002017-08-09T17:28:49.951-04:00Connecting Dynamics 365 On-Premise to Power BIIf you're looking to setup the integration between Dynamics 365 On-Premise (using IFD) and Power BI, you may stumble upon this lovely TechNet: <a href="https://technet.microsoft.com/en-us/library/dn708055.aspx#PBI_op">https://technet.microsoft.com/en-us/library/dn708055.aspx#PBI_op</a><br />
<br />
All seems great, right? Well, that would be the case if all the steps were accurate...<br />
<br />
To start, the PowerShell commands in step 1 to enable OAuth on the Dynamics 365 Server just do not work. The first three will work fine but upon execution of the 4th to actually set the change, it will throw an error. Instead, use this syntax to accomplish the same thing:<br />
<br />
<i>Add-PSSnapin Microsoft.Crm.PowerShell</i><br />
<i>$ClaimsSettings = Get-CrmSetting -SettingType OAuthClaimsSettings</i><br />
<i>$ClaimsSettings.Enabled = $true</i><br />
<i>Set-CrmSetting -Setting $ClaimsSettings</i><br />
<i><br /></i>
Afterwards, run <i>Get-CrmSetting -SettingType OAuthClaimsSettings</i> and you should see enabled set to "True" as shown below.<br />
<i><br /></i>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg8VegZrvGfEA-DOZGnrG9fj7Se6J250riaNQBh2vcO-vGqZN0XNvjLTwVIpyiy5mzaccfvbXT8DcqrbmZ-dYfhi0FsZh6llKbfvVNV09Mr3ensoH6vnoLfqFdZZLPcGtjrBwFy4EBS0qff/s1600/79.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="198" data-original-width="847" height="147" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg8VegZrvGfEA-DOZGnrG9fj7Se6J250riaNQBh2vcO-vGqZN0XNvjLTwVIpyiy5mzaccfvbXT8DcqrbmZ-dYfhi0FsZh6llKbfvVNV09Mr3ensoH6vnoLfqFdZZLPcGtjrBwFy4EBS0qff/s640/79.png" width="640" /></a></div>
<br />
Moving onward to step 3 in the process where we register the Power BI Desktop OAuth 2.0 client with ADFS. You will notice in the instructions that it states "open a Windows PowerShell window and run the following PowerShell command <b>on the PC where you are running Power BI Desktop</b>". This is simply wrong. The "Add-AdfsClient" command is for... ADFS. Shocking, I know. So ignore the statement about the PC running Power BI and run the command provided on your ADFS server instead. Luckily, this one is correct and works. If you run <i>Get-AdfsClient </i>afterwards, you will see the addition of Power BI.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEipczauY_2mqBat-ofivdJCZzyTBDNjPWMbkaDd55bX0AJI7BzVXLlB7ah8R01prwH8CfPZvZe6R6QoIFDtDlsR_qFctGOQc10bzbXR4fb7BoVRr890y0qvowAeJsBcgf4gvqMcTy2eQ1l0/s1600/80.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="379" data-original-width="853" height="284" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEipczauY_2mqBat-ofivdJCZzyTBDNjPWMbkaDd55bX0AJI7BzVXLlB7ah8R01prwH8CfPZvZe6R6QoIFDtDlsR_qFctGOQc10bzbXR4fb7BoVRr890y0qvowAeJsBcgf4gvqMcTy2eQ1l0/s640/80.png" width="640" /></a></div>
<i><br /></i>
One last helpful tip - When copying commands from websites (even here), I always recommend pasting into Notepad before bringing them where they need to be executed (e.g. SSMS, PowerShell, etc...). This will get rid of any problematic formatting.<br />
<br />
That's really it from a server perspective. Best of luck!Gagehttp://www.blogger.com/profile/06440235801891990171noreply@blogger.com28Gainesville, FL, USA29.6516344 -82.32482619999996129.4309209 -82.647549699999956 29.872347899999998 -82.002102699999966tag:blogger.com,1999:blog-5336844806027714065.post-16667023989953249232017-07-12T13:04:00.001-04:002017-07-13T12:08:32.534-04:00Issue Installing CRM 2016 SRS Data Connector with SQL 2016In my last post, I mentioned that I had received some Windows Server 2016 boxes to test setup of CRM 2016/Dynamics 365. In addition to them being the 2016 OS, they also came with SQL Server 2016. The installation of CRM went off without a hitch (after working through the Search service problem) and the databases created in SQL as expected.<br />
<br />
However, when it came to installation of the SRS Data Connector, things got a little hairy. The installation began but quickly threw this error message:<br />
<br />
<i>Error| System.Exception: Action Microsoft.Crm.Setup.SrsDataConnector.AddBindingRedirectForRdlHelper failed. ---> System.IO.DirectoryNotFoundException: Could not find a part of the path 'C:\Program Files\Microsoft SQL Server\MSRS13.MSSQLSERVER\Reporting Services\ReportManager\web.config'.</i><br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhzNfPEiX1O_0wGzdvT34R8GRsDRedEfAGVq5z1XGAJh7bqjoOkt2GPiOeYazeYkdhn6PLSF8qDGGg34jvLlhY_VKV_48Tjgkd0SUhJUC7X3nIkM0jFnCiCEh5lRSr21LcDiTrI3B_hztlF/s1600/73.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="409" data-original-width="503" height="325" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhzNfPEiX1O_0wGzdvT34R8GRsDRedEfAGVq5z1XGAJh7bqjoOkt2GPiOeYazeYkdhn6PLSF8qDGGg34jvLlhY_VKV_48Tjgkd0SUhJUC7X3nIkM0jFnCiCEh5lRSr21LcDiTrI3B_hztlF/s400/73.png" width="400" /></a></div>
<br />
To make a long story short, SQL 2016 no longer creates/uses the path specified in the error message and the RTM Data Connector installer does not check the version of SSRS being used so it will just keep trying to use that directory.<br />
<br />
Now, I had some previous experience installing the Data Connector with SQL 2016 involved. From that, I recalled that the installer, when asked to check for updates on the first screen, actually went out and got some new install bits. This time around I was not so lucky – it just told me there were no updates available (I even verified that the Windows Firewall was off and that the box was allowing Windows Updates)… it had internet access but if you’re reading this and your SQL server does not have access to the internet, you should keep reading. Regardless, I needed a solution and the internet was not full of suggestions with this being pretty new technology.<br />
<br />
I decided to check the Microsoft Update Catalog to see if I could download and manually patch the update in. To my delight, I came across a listing for “Setup Update for Microsoft Dynamics CRM 2016 Reporting Extensions” and this ultimately helped solve my issue. Here is a step-by-step process of what to do if you are facing the same situation:<br />
<br />
1.<span style="white-space: pre;"> </span>If your initial install failed, go into the server’s control panel and uninstall the data connector.<br />
<br />
2.<span style="white-space: pre;"> </span>Go to <a href="http://www.catalog.update.microsoft.com/">http://www.catalog.update.microsoft.com/</a><br />
<br />
3.<span style="white-space: pre;"> </span>Search for “3129794” and you should get back one listing. Click the download button.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjw1BWdCrhj4uTq-c79DQwpxbm2K3nwrqmSzEZGIcPX2gThDwb3Nd3ysZBCSjLmesp0ADbFTaPj559B8lpP8rYpUDK_UR-7hFESAF2pbJfNOsYxHdHRK_eFZRtDytKdVrzw_ATIiQQG2osK/s1600/74.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em; text-align: center;"><img border="0" data-original-height="135" data-original-width="1126" height="75" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjw1BWdCrhj4uTq-c79DQwpxbm2K3nwrqmSzEZGIcPX2gThDwb3Nd3ysZBCSjLmesp0ADbFTaPj559B8lpP8rYpUDK_UR-7hFESAF2pbJfNOsYxHdHRK_eFZRtDytKdVrzw_ATIiQQG2osK/s640/74.png" width="640" /></a></div>
<br />
<br />
4.<span style="white-space: pre;"> </span>A new screen will pop up with a ton of .cab files. Find the one named “srs_kb3129794_amd64_1033_b585b78e247dc7611e1e406a6c132cdee112690c.cab” (just look for 1033) and download that. I will admit that I am not sure of the purpose of all these files but the 1033 one did the trick for me. Later on, you will notice that another file we work with is also “1033” so that probably has something to do with it.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgSQJNkuAD9DvWj3wVKNCBqUWafc4muuOW00RXHVHrK8unFad_A__sL8oXMVc8YqrBMuKK8RVFCnPmx-5fFVcXNwfhyphenhyphen_Z83TJLuAv39InRHu1CYlVotaPC5bxPkaD4AHzQ9BcNVzVMphpNw/s1600/75.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em; text-align: center;"><img border="0" data-original-height="572" data-original-width="611" height="373" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgSQJNkuAD9DvWj3wVKNCBqUWafc4muuOW00RXHVHrK8unFad_A__sL8oXMVc8YqrBMuKK8RVFCnPmx-5fFVcXNwfhyphenhyphen_Z83TJLuAv39InRHu1CYlVotaPC5bxPkaD4AHzQ9BcNVzVMphpNw/s400/75.png" width="400" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<br />
5.<span style="white-space: pre;"> </span>Once you have the .cab file downloaded to the server, open it up to reveal the patch file. Right-click on it and choose “Extract”.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEigg0InDt0KVzv45f3isAt9ftRKy6fxuGCtIu3G8FNVd3JNYTp2CNTxBesb37MFTspQdzmAi9EtGrbovWtVxw0G0sJqc2NwZK_u9smJ81plBXfXYE-e6vBO_tB6SWFbhnMnO4V1HZXVZEXk/s1600/76.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em; text-align: center;"><img border="0" data-original-height="111" data-original-width="589" height="75" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEigg0InDt0KVzv45f3isAt9ftRKy6fxuGCtIu3G8FNVd3JNYTp2CNTxBesb37MFTspQdzmAi9EtGrbovWtVxw0G0sJqc2NwZK_u9smJ81plBXfXYE-e6vBO_tB6SWFbhnMnO4V1HZXVZEXk/s400/76.png" width="400" /></a></div>
<br />
6.<span style="white-space: pre;"> </span>After the extraction, you will have the .msp file available for use. Go to the directory of the SRS Data Connector’s installation files and locate a folder named “Update”. In here, you will see another .msp file named “Srs_KB3121695_Amd64_1033”.<br />
<br />
7.<span style="white-space: pre;"> </span>Cut and paste that file out of the “Update” folder – just put it anywhere else on the server.<br />
<br />
8.<span style="white-space: pre;"> </span>Copy and paste the .msp you just downloaded into the now blank “Update” folder - essentially replacing it.<br />
<br />
You should go from this:<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgrxz6E4iHxbJ4mPaGibdjE9uRby5nw-UBV_gbuAz0WbMbGoOg-PxpFl52hHDZohtar8LvRT50of0fUp22vRxj08U8f_kIxHDKumDaKXyezZQhPmLGFQUbyAo2_K5NU_astVuqKtth-LgT6/s1600/77.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em; text-align: center;"><img border="0" data-original-height="95" data-original-width="583" height="65" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgrxz6E4iHxbJ4mPaGibdjE9uRby5nw-UBV_gbuAz0WbMbGoOg-PxpFl52hHDZohtar8LvRT50of0fUp22vRxj08U8f_kIxHDKumDaKXyezZQhPmLGFQUbyAo2_K5NU_astVuqKtth-LgT6/s400/77.png" width="400" /></a></div>
To this:<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi10Jv3DcnjEa1tXNy0SvCACQEMLPqEu_KYkqylPIdziF40GJqmpOoO-ZtnpeQX_vcKFbI4nrTXv0blBEW2nbI8hQtJEOpJs77YoN4tz_p2oZTVRnMPoVzhAymey3osP1N5DciA36ODPI_M/s1600/78.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em; text-align: center;"><img border="0" data-original-height="98" data-original-width="583" height="66" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi10Jv3DcnjEa1tXNy0SvCACQEMLPqEu_KYkqylPIdziF40GJqmpOoO-ZtnpeQX_vcKFbI4nrTXv0blBEW2nbI8hQtJEOpJs77YoN4tz_p2oZTVRnMPoVzhAymey3osP1N5DciA36ODPI_M/s400/78.png" width="400" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
9.<span style="white-space: pre;"> </span>Re-run the installer as normal and it should complete without issue.<br />
<br />
<br />
Just to note a few things:<br />
<ul>
<li>I initially played a bunch of trial and error with getting the update patched in before I discovered the ability to replace the .msp in the Update folder. I first went down the path of editing the config.xml to include the patch and then called the installer from a command line specifying it to use the config file. This is how I have always patched in updates for the server installer but it does not seem to work the same way for the Data Connector. I also tried loading the patch into the temp files that the installer looks to… also didn’t work.</li>
</ul>
<ul>
<li>If your base installer’s update file has a different number than “1033” at the tail end of it, you may need to match it up with the correct .cab file from the Update Catalog. I did not encounter this scenario so I cannot test or prove out this theory but I think logic dictates… </li>
</ul>
<ul>
<li>There is another blog out there about applying SP1/2 to the failed installation and then manually editing file structure. I will not discredit that being a possible workaround but personally, I do not like the idea of relying on an update to fix a broken install.</li>
</ul>
<br />
Good luck!Gagehttp://www.blogger.com/profile/06440235801891990171noreply@blogger.com6Gainesville, FL, USA29.6516344 -82.32482619999996129.4309209 -82.647549699999956 29.872347899999998 -82.002102699999966tag:blogger.com,1999:blog-5336844806027714065.post-26553298710121676912017-07-06T21:42:00.000-04:002017-07-12T09:44:34.797-04:00Issue Installing CRM 2016 (Dynamics 365) on Windows Server 2016I recently got my hands on some Windows Server 2016 boxes and wanted to test out the CRM 2016/Dynamics 365 installation process on them. Preparation began as usual and I kicked off the wizard. Some time after that I was presented with the following error message:<br />
<br />
<i>Action.Microsoft.Crm.Setup.Common.InstallWindowsSearchAction failed. The service cannot be started, either because it is disabled or because it has no enabled devices associated with it. (Exception from HRESULT: 0x80070422)</i><br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj33BOeo_zyip64gUM6PDEvAKMwFXS6vbakougHxZc8vt7nI2pENuw7nAp4Gp0jalk9UiMlmV2qF22-UzwlkuOjbl6I_D4wQT5-FHvs6Wl1dV3Iz3vAZp2A8EjPxugZP-y2CId7HRJimemV/s1600/70.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="399" data-original-width="492" height="322" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj33BOeo_zyip64gUM6PDEvAKMwFXS6vbakougHxZc8vt7nI2pENuw7nAp4Gp0jalk9UiMlmV2qF22-UzwlkuOjbl6I_D4wQT5-FHvs6Wl1dV3Iz3vAZp2A8EjPxugZP-y2CId7HRJimemV/s400/70.png" width="400" /></a></div>
<br />
What I quickly learned was that the Windows Search service, while coming pre-installed on Windows Server 2016, is set to disabled by default.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgzCAzXL26hJ33ezNe8FZC2wG_jhULH7f18RzwAxBsv-4WVsAmGXzc0b2pkyvU8Mzg-6M0KJsypIkPlS6NOaPiSdlC8fGw7s7V4Zfmk8qCBMLulZaVGv8n4aRJSJPHBQeRR1ZJO726JKGCm/s1600/71.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em; text-align: center;"><img border="0" data-original-height="32" data-original-width="430" height="27" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgzCAzXL26hJ33ezNe8FZC2wG_jhULH7f18RzwAxBsv-4WVsAmGXzc0b2pkyvU8Mzg-6M0KJsypIkPlS6NOaPiSdlC8fGw7s7V4Zfmk8qCBMLulZaVGv8n4aRJSJPHBQeRR1ZJO726JKGCm/s400/71.png" width="400" /></a></div>
<br />
<br />
I enabled the service by setting it to automatic startup, started it, and then hit retry on the error diagloue from the CRM installation wizard. The installation continued and finished with no further issues.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiWgEaIDSy69rrWE7nQzE2EjIolqDw4r0cGBW_0Hi4VuDzDeTNfoEL4vIAcFKSa7HY9JPyHpe6bwB6vLIwf0UalhWePeRSzcmg0q4ZsbD9wPtxRZ3eJfg6lSEK1cn4wb-vCpMUhh4wfsI4M/s1600/72.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em; text-align: center;"><img border="0" data-original-height="370" data-original-width="346" height="400" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiWgEaIDSy69rrWE7nQzE2EjIolqDw4r0cGBW_0Hi4VuDzDeTNfoEL4vIAcFKSa7HY9JPyHpe6bwB6vLIwf0UalhWePeRSzcmg0q4ZsbD9wPtxRZ3eJfg6lSEK1cn4wb-vCpMUhh4wfsI4M/s400/72.png" width="373" /></a></div>
<br />
<br />
I love the easy fixes!Gagehttp://www.blogger.com/profile/06440235801891990171noreply@blogger.com2Gainesville, FL, USA29.6516344 -82.32482619999996129.4309209 -82.647549699999956 29.872347899999998 -82.002102699999966tag:blogger.com,1999:blog-5336844806027714065.post-48109125483495356732017-06-29T20:30:00.000-04:002017-07-12T09:23:14.619-04:00High Availability and Disaster Recovery Options for Dynamics 365 (CRM)Planning the infrastructure for your Dynamics 365 environment is a critical step in the deployment process, especially when the software is mission critical to business needs and day-to-day operations. In scenarios like these, it is imperative to have high availability and even disaster recovery plans in place. So the question is: What options do you have when it comes to Dynamics 365 on premise? In this article, we will break it down from both an application (Dynamics 365) and database (SQL Server) perspective.<br />
<br />
<b><u>High Availability – Dynamics 365</u></b><br />
For most companies, having high availability for their Dynamics 365 deployment is a must and the setup for this is similar to that of other web-based applications. Keep in mind that through this section we are strictly referring to Dynamcis 365 servers with the “Front End” or “Full” role – in other words, the servers that host the website in IIS. Having multiple “Back End”-only servers (those with the Async and Sandbox services) is also a good idea but those will natively load balance themselves if they are in the same deployment.<br />
<br />
<div>
<ul>
<li><b>Network Load Balancing</b> – Probably the most obvious method for high availability is running multiple Dynamics 365 servers in a load-balancing configuration. This will not only help with carrying the day-to-day load of traffic but also serve as the foundation for a good high availability option. If a server were to fail, just pop it out of the NLB pool. Load balancing comes in a few different flavors because of all the applications out there but mainly it comes down to two options – hardware and software.</li>
</ul>
<ul><ul>
<li><b>Hardware Load Balancing</b> involves the use of a third-party appliance such as F5 or NetScaler that sits in front of the Dynamics 365 servers to handle which server receives the user requests. While this is the preferred option as it does not create any additional processes for the servers to handle and usually provides a wider array of configuration options (e.g. monitoring, security, filtering, etc…), it can be more difficult and much more costly to implement.</li>
</ul>
</ul>
<ul><ul>
<li><b>Software Load Balancing</b> on the other hand is relatively easy to setup and in the case of Windows NLB, is free, as you have already paid for your Windows Server licenses. Critics of software load balancing will contend that it is not “true” high-availability due to the lack of many key features found in hardware load balancing. The fact stands that Windows NLB is just Round Robin DNS so if a server were to go down, requests would still be sent to the faulted server until it is told otherwise.</li>
</ul>
</ul>
<ul><ul>
<li>As one can probably infer, this is simply a cost vs. ROI decision – which is the case with most IT situations. If the hardware option is being considered, make sure to reach out to your appliance vendor to ensure there are no known issues with it and Dynamics 365. It is also a good idea to inquire about documentation for setup. For more information about load balancing Dynamics 365 in general and the required configurations, check out this TechNet: https://technet.microsoft.com/en-us/library/hh699803.aspx. </li>
</ul>
</ul>
</div>
<div>
<ul>
<li><b>Backup Server(s)</b> – While this method may be a little more rigid, it is still effective and again, has a couple options. The meat and potatoes of this route is having a server to fall back to in the event that your primary Dynamics 365 server(s) fails and NLB has not been implemented.</li>
</ul>
<ul><ul>
<li><b>VM Snapshots</b> – If you are reading this, you most likely understand the concept of VM snapshots so we will not dive too heavily into this. The idea is to have automatic snapshots taken automatically on a set interval that the Dynamics 365 server can be reverted to or new server built from in the event of failure. Reverting the existing server is the easier option but also the more risky of the two. Spinning up a new server is safer but more involved – and requires the shutdown of the existing server as you will need to use the same host name and IP address.</li>
</ul>
</ul>
<ul><ul>
<li><b>Laying in wait</b> – We have had some customers opt for this route as the return to uptime is a little quicker and/or VMs were not being used. Dynamics 365 deployments can obviously be comprised of multiple servers – but not all need to be active or enabled. The concept here is to build a secondary Dynamics 365 server as part of the deployment but leave it disabled until it is needed. If the primary server were to fail, all that would be required is enabling of the server via the Deployment Manager and changes to DNS (and firewall rules, if applicable).</li>
</ul>
</ul>
</div>
<div>
<br />
<br /></div>
<div>
<b><u>High Availability – SQL Server</u></b></div>
<div>
Now that we have covered high availability from an application perspective, what about the database? Don’t worry! Microsoft has that covered too!</div>
<br />
<div>
<ul>
<li><b>SQL Server Failover Cluster</b> – There is nothing new about this concept. Two SQL Servers are setup to use a shared disk, one server goes down and the other picks up the load. When installing Dynamics 365 just make sure to point connection strings to the cluster name and not a single node and you should not have any issues but be sure to test failover prior to going live. Just to note - although you can install Dynamics 365 to a SQL Server cluster configured for either active-active or active-passive clustering, the cluster will function in an active-passive manner. While clustering is tried and true, Microsoft decided to go a step further with...</li>
</ul>
<ul>
<li><b>SQL Server Always On</b> – New to SQL Server 2012 (Enterprise Edition), Always On introduced the concept of Availability Groups. An Availability Group is simply a container for a set of databases that fail over together. For purposes of Dynamics 365 databases, this is important considering there are always at least two databases per deployment. With Always On, the databases in the Availability Groups are synchronized amongst all the configured replicas. We won’t get into the details of setting up Always On (there are tons of articles out there already) but be sure to reference this TechNet for how to configure Dynamics 365 with SQL Always On: https://technet.microsoft.com/en-us/library/jj822357.aspx </li>
</ul>
</div>
<div>
<br /></div>
<br />
<div>
<b><u>Disaster Recovery – Dynamics 365 and SQL Server</u></b></div>
<div>
<div>
While having a single server fail is far more likely than seeing your entire data center swallowed into a pit only to be burnt up in the Earth’s core, it is a situation that should also be planned for! Unlike the sections regarding high availability, we need to think of a DR scenario in terms of the entire infrastructure – both Dynamics 365 and SQL Server – because if there is a disaster, chances are it is taking both so these plans go hand-in-hand. </div>
<div>
<br /></div>
<div>
Over the years, we have implemented CRM/Dynamics 365 disaster recovery plans for numerous customers and as a result, have learned (what we consider) the best option – which is what we will be covering. This is not to say there are no other viable methods (such as VM snapshot migrations or SQL Log Shipping), but we will keep focus on our preferred option. In a nutshell, we are going to have a separate, self-contained Dynamics 365 environment in the DR data center that has data synced from the production SQL servers in the primary site.</div>
<div>
<b><br /></b></div>
<div>
<b>SQL Server</b></div>
<div>
Let us start from a database perspective since it is a little more complex and setting up Dynamics 365 for DR will require this information. As previously touched on, SQL Always On will come in handy yet again and recall the concept of Availability Groups as this will play heavy into this strategy.</div>
</div>
<div>
<br /></div>
<div>
<div>
For DR scenarios with Dynamics 365, we will need two Availability Groups in SQL AlwaysOn – one for the MSCRM_CONFIG database to be synchronized between the two primary data center nodes and another to synchronize the Organization_MSCRM database between not only the two primary data center SQL Servers but also a third SQL Server in your DR data center. The reason for this will become clear as you keep reading.</div>
</div>
<div>
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg61Fb2ndC0p3Pyr9bGXXefxYiTwG7S2qVbt9p-XgmFUaXyAv-B1OBMnsafi5qU4EyATvVYA0pE-WBefhHW6_9SWRgZjXUTjL_ouTRnMD8dS6RCjZvuOPtvOkt11UMtrk8XmsCQsd9_hR0b/s1600/69.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="516" data-original-width="935" height="352" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg61Fb2ndC0p3Pyr9bGXXefxYiTwG7S2qVbt9p-XgmFUaXyAv-B1OBMnsafi5qU4EyATvVYA0pE-WBefhHW6_9SWRgZjXUTjL_ouTRnMD8dS6RCjZvuOPtvOkt11UMtrk8XmsCQsd9_hR0b/s640/69.png" width="640" /></a></div>
<div>
<br /></div>
<div>
<div>
<b>Dynamics 365</b></div>
<div>
Going into the Dynamics 365 server installation(s), the third SQL node should already be built and ready with SQL Always On. Unlike the installation of the Dynamics 365 servers in the primary data center, you do NOT want to set the SQL connection to use the Availability Group but rather just the SQL Server located in the DR data center. The reasoning behind this is the MSCRM_CONFIG database – this database is specific per deployment of Dynamics 365 and two cannot exist in the same SQL server/instance (nor can the name be changed). Remember that this Dynamics 365 DR deployment is to be isolated from the primary.</div>
<div>
<br /></div>
<div>
At this point, you may be asking yourself how this all comes together. When the primary data center goes down (mainly both primary SQL nodes), the organization database will be failed over to the third node in DR. Once that happens, launch the deployment manager on the Dynamics 365 DR Server and import the organization database into the deployment. That should take about 5 minutes and then Dynamics 365 will be back up and running.</div>
<div>
<br /></div>
<div>
Great! We have the servers all setup in DR and are ready for that giant pit to open up beneath the data center! Now what? RUN THROUGH A TEST DISASTER RECOVERY SCENARIO! This cannot be stressed enough – you do not want to wait for a real disaster to find some small configuration issue messed up the entire plan.</div>
</div>
Gagehttp://www.blogger.com/profile/06440235801891990171noreply@blogger.com4Gainesville, FL, USA29.6516344 -82.32482619999996129.4309209 -82.647549699999956 29.872347899999998 -82.002102699999966tag:blogger.com,1999:blog-5336844806027714065.post-3664707215418408102017-06-05T19:54:00.000-04:002017-06-06T15:06:43.450-04:00URL Redirect Based on IP AddressAs you are most likely aware, CRM/D365 has two URLs to access it when setup for IFD. The first URL, referred to as the “internal URL”, will allow authentication to be passed through and not display the ADFS login page for credentials. As the name suggests, this URL should only be available from within the network and not exposed out over the internet. The second URL, (not surprisingly) referred to as the “external URL”, will not pass through authentication and will display the ADFS login form for users to enter credentials. This URL is the one exposed out over the internet but is also available from within the network.<br />
<br />
Customers often like the convenience of not having to enter credentials using the internal URL but do not like having two URLs to use. As a result, we are tasked with providing a solution to this dilemma. Back in the days of ADFS 2.0, we could easily handle this with a much simpler tweak in IIS of the ADFS server. Unfortunately, with the newer versions of ADFS no longer using IIS as its backbone this is no longer an option and a URL Rewrite rule now must be implemented on the CRM/D365 server. Here’s how:<br />
<br />
1.<span class="Apple-tab-span" style="white-space: pre;"> </span>Open IIS on the CRM/D365 Front End (web) Server and go to the URL Rewrite module of the CRM Website.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi1uzneY1nluJy6xkVK_2R2c4pfomgb4EDvRV9HG_QLcYMrFWUbqrKoMsSf4e5tV9S-I3gN64PDpYYSxjlAWTtEZD8w26DtzFrE3Ag-VoWzeB-T4oFsHSL2YzRDPGAxhDfb3C5pcMw78-J3/s1600/64.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="244" data-original-width="1264" height="123" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi1uzneY1nluJy6xkVK_2R2c4pfomgb4EDvRV9HG_QLcYMrFWUbqrKoMsSf4e5tV9S-I3gN64PDpYYSxjlAWTtEZD8w26DtzFrE3Ag-VoWzeB-T4oFsHSL2YzRDPGAxhDfb3C5pcMw78-J3/s640/64.png" width="640" /></a></div>
<br />
2.<span class="Apple-tab-span" style="white-space: pre;"> </span>Click the link to “Add Rule(s)” and just select “Blank Rule” under Inbound rules.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhWoQdL6HRmwMdY668uTswaTUkO0RNA4jeC_3HV1oo9VYZBnBOyn3dk57wHsPDpho6NFdb-SkXcMY-BNxVHZdMkWdnzQc3EYuWAVolXNJrzYoayrWVLpH4iZDfpxM8FxA2Ki5e59v2ZZ7PD/s1600/65.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="136" data-original-width="692" height="124" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhWoQdL6HRmwMdY668uTswaTUkO0RNA4jeC_3HV1oo9VYZBnBOyn3dk57wHsPDpho6NFdb-SkXcMY-BNxVHZdMkWdnzQc3EYuWAVolXNJrzYoayrWVLpH4iZDfpxM8FxA2Ki5e59v2ZZ7PD/s640/65.png" width="640" /></a></div>
<br />
3.<span class="Apple-tab-span" style="white-space: pre;"> </span>Give the rule an applicable name and in the Match URL section, leave both the ”Requested URL” and “Using” fields as their defaults (shown in screen capture). In the “Pattern” field type in (.*).<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjCk_sKU07mfoGlopRccBylMuCcKbIXQG83unp1iGCfjNagz8zLnEz1mGaWzxAzafpALjbVNL1OCE8DkcLDEG9U78qff9IAXTrxjyqrCoyNZF72NMqCi2ERl4jOf-ayh3xlRFJUNz2nYsGV/s1600/66.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="338" data-original-width="695" height="311" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjCk_sKU07mfoGlopRccBylMuCcKbIXQG83unp1iGCfjNagz8zLnEz1mGaWzxAzafpALjbVNL1OCE8DkcLDEG9U78qff9IAXTrxjyqrCoyNZF72NMqCi2ERl4jOf-ayh3xlRFJUNz2nYsGV/s640/66.png" width="640" /></a></div>
<br />
4.<span class="Apple-tab-span" style="white-space: pre;"> </span>This is where it gets fun. In the Conditions section, you will add three rules in the order shown below.<br />
<br />
a.<span class="Apple-tab-span" style="white-space: pre;"> </span>For the first rule, change “crmorgname” to the actual name of your organization.<br />
b.<span class="Apple-tab-span" style="white-space: pre;"> </span>For the second rule, change the pattern to match that of your internal IP range.<br />
c.<span class="Apple-tab-span" style="white-space: pre;"> </span>Just enter the third rule as shown – no changes needed – ([^\.]*)\.(.*)<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhWfp1dLxO8CHai3OqYenvLhC282oKEr3ltWe5nIsiHFf9BxPiyZUAKPUJmbSLClhOPel2i7cYfsy3s11wkeIpmFpR1333UL7sK3bMUDI3NUjCJq3l6xK5-tdexG8tADDcWEyEqA9c8-F4C/s1600/67.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="326" data-original-width="679" height="307" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhWfp1dLxO8CHai3OqYenvLhC282oKEr3ltWe5nIsiHFf9BxPiyZUAKPUJmbSLClhOPel2i7cYfsy3s11wkeIpmFpR1333UL7sK3bMUDI3NUjCJq3l6xK5-tdexG8tADDcWEyEqA9c8-F4C/s640/67.png" width="640" /></a></div>
<br />
5.<span class="Apple-tab-span" style="white-space: pre;"> </span>In the Action section, change the “Action type” to “Redirect” and for the Redirect URL enter your internal CRM/D365 URL followed by the syntax shown in the screenshot. Leave “Append query string” checked and set the Redirect type to “Permanent (301)”.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhXnVRrfgmerZTXyS_vvYayk9xT3kB04ZslwDbLER7goAFNFB4s-MpW5OJ0cvUUduDaFCP3U0xqQVdVw3heHhj0xtlH9Xp-mmfAhaPsj1u7H5xFB83ROChBxZOZj3AwkLAcHfhaC663vBeE/s1600/68.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="285" data-original-width="680" height="268" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhXnVRrfgmerZTXyS_vvYayk9xT3kB04ZslwDbLER7goAFNFB4s-MpW5OJ0cvUUduDaFCP3U0xqQVdVw3heHhj0xtlH9Xp-mmfAhaPsj1u7H5xFB83ROChBxZOZj3AwkLAcHfhaC663vBeE/s640/68.png" width="640" /></a></div>
<br />
6.<span class="Apple-tab-span" style="white-space: pre;"> </span>Apply the URL Rewrite rule and test it by going to the external URL from a machine that has an IP address matching that of the ranges specified on your network. If everything was setup correctly, the external URL will redirect to the internal URL and pass-through authentication will occur.<br />
<div>
<br /></div>
Gagehttp://www.blogger.com/profile/06440235801891990171noreply@blogger.com0Gainesville, FL, USA29.6516344 -82.32482619999996129.4309209 -82.647549699999956 29.872347899999998 -82.002102699999966tag:blogger.com,1999:blog-5336844806027714065.post-27368866210828419802017-05-17T17:07:00.001-04:002017-05-17T17:09:44.464-04:00Tracing ADFS Logon Failures - Enabling ADFS AuditingIf you are ever faced with a situation where you are seeing a ton of logon failures in your ADFS logs and you’re not sure where they are coming from, you will soon learn that the basic logs do not provide any insight into their origins. But fear not! Some additional auditing can be enabled to help track down your problem child.<br />
<br />
You will likely start with “Event 342 – The user name or password is incorrect” in the ADFS Admin logs – this is about as useless as it gets.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgxSFjWLPrB4C8dn6HApF-7E7LkT8GV5HsVc7CeczjED6hTETOr9D37WMOfh-xsBW9KTgiI5JKxG88HqINOSvDHteUB6xrRo5E26NPo5hbxejcCzw0ya6EW9jcYKuKejXX8L4FinaMsc-4b/s1600/59.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="331" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgxSFjWLPrB4C8dn6HApF-7E7LkT8GV5HsVc7CeczjED6hTETOr9D37WMOfh-xsBW9KTgiI5JKxG88HqINOSvDHteUB6xrRo5E26NPo5hbxejcCzw0ya6EW9jcYKuKejXX8L4FinaMsc-4b/s640/59.png" width="640" /></a></div>
<br />
In my scenario, I was seeing about 1,500 of those events per minute. Needless to say, something was wrong but we had no idea what could possibly be trying to authenticate that much. Luckily, ADFS has some built-in auditing that can be of more use in situations like this. Start out by opening the ADFS Management Console and choose the option “Edit Federation Service Properties…” (it’s in the column on the right). Once in the properties screen, click on the “Events” tab. Here you should see 5 checkboxes – 2 of which are unchecked. Check those boxes (Success audits and Failure audits) and click OK.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgjD5PIHZiP-ltcTq80QaOMOMcX6vSzyJtC1ekeZp9t7zOPgaMzMc1zSgv51OAGYJMrgZKYnxDh1k6ZMCMrugrku6WeRjaznRct6-cAC15qfdyZzcLSwcaw17hSaQ_O1AU3pAvt4mFv4fjK/s1600/60.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgjD5PIHZiP-ltcTq80QaOMOMcX6vSzyJtC1ekeZp9t7zOPgaMzMc1zSgv51OAGYJMrgZKYnxDh1k6ZMCMrugrku6WeRjaznRct6-cAC15qfdyZzcLSwcaw17hSaQ_O1AU3pAvt4mFv4fjK/s1600/60.png" /></a></div>
<br />
Now that ADFS is setup for auditing, you need to tell the server to allow it. Head on over to the Local Security Policy of the ADFS server – this can be found from the Server Manager. Once here, drop down “Advanced Audit Policy Configuration” and then “System Audit Policies – Local Group Policy Object”. Locate the “Object Access” policy and then open the “Audit Application Generated” subcategory. Check the three boxes on this screen and then click OK.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhH2EvUykt8B0OTgYn0-HDah3DDekXmriUiBEeESXO2MLFBzd_jwuT1rSAG9w7wgbfHlbOCMjeJomP38jH5JUCPRfYEH_S8DIHhMuELZ7KmxtxmR7hLqMNcSofqVno2MUEhaFK7SW-hQsVa/s1600/61.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhH2EvUykt8B0OTgYn0-HDah3DDekXmriUiBEeESXO2MLFBzd_jwuT1rSAG9w7wgbfHlbOCMjeJomP38jH5JUCPRfYEH_S8DIHhMuELZ7KmxtxmR7hLqMNcSofqVno2MUEhaFK7SW-hQsVa/s1600/61.png" /></a></div>
<br />
<br />
You should now be all set to revisit your Event Viewer. Look into the Security events under the Windows Logs and you should now see events with ID 411 for “Classic Audit Failure” with the source as “AD FS Auditing”.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjoG7ml-ID3vrREFOWdJFDXn-UcLjWfoOpNI6UP3x3auMTN0ZGvKpoJDLpQ59fyUmtxDI99QQjStN5TVz9IByJkuWLxzGHHr06h0fKVuLerphhiLTwxz9rXbfKJc8_KwTTLaiPMqZOEt6m2/s1600/62.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="182" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjoG7ml-ID3vrREFOWdJFDXn-UcLjWfoOpNI6UP3x3auMTN0ZGvKpoJDLpQ59fyUmtxDI99QQjStN5TVz9IByJkuWLxzGHHr06h0fKVuLerphhiLTwxz9rXbfKJc8_KwTTLaiPMqZOEt6m2/s640/62.png" width="640" /></a></div>
<br />
Go ahead and open one of those bad boys up…. Ahhhh finally some useful information! A quick look through will reveal the Client IP, which should be the machine sending the invalid authentication requests to ADFS.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiacL5RwXWkaSMRMSO3J1weptHNLHx_k4NWoZ3RTsWGLh7bdpNOOL2KaIVN7VwodBK6-1xNwF2BhehHiCceDyo78RnbBztNN2-MzTGofdOTa9Np3FgEyRowAbepQfhoblJYcmOORr5hIGSf/s1600/63.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiacL5RwXWkaSMRMSO3J1weptHNLHx_k4NWoZ3RTsWGLh7bdpNOOL2KaIVN7VwodBK6-1xNwF2BhehHiCceDyo78RnbBztNN2-MzTGofdOTa9Np3FgEyRowAbepQfhoblJYcmOORr5hIGSf/s1600/63.png" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
The process from here is self-explanatory but head on over to the machine with the offending client IP address and find out what the problem is. In my case, there was a long-forgotten email router still setup which kept trying to access CRM. After figuring out the problem, it is recommended to disable auditing.<br />
<div>
<br /></div>
Gagehttp://www.blogger.com/profile/06440235801891990171noreply@blogger.com3Gainesville, FL, USA29.6516344 -82.32482619999996129.4309209 -82.647549699999956 29.872347899999998 -82.002102699999966tag:blogger.com,1999:blog-5336844806027714065.post-29417360204062607962017-04-26T11:50:00.001-04:002017-04-26T11:50:24.732-04:00To Run The Email Router Configuration Manager, You Must Be A Local AdministratorJust had an unusual error message
pop-up when trying to open the Email Router Configuration Manager following the
update to Dynamics 365 (on-prem). It was something I had never seen before with
previous versions of CRM – 2016 included. The message read:<br />
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<o:p></o:p></div>
<div class="MsoNormal">
<i>To run the Email Router Configuration Manager, you must
be a local administrator. Make sure that you are a member of the Administrator
group before you start this program.<o:p></o:p></i></div>
<div class="MsoNormal">
<i><br /></i></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhneyfkTY4MQgQkOkJFxCEjX4tBF0_fOQJKchRqPN_Jfds5yBYBQZmxcV3TpOBrXJwtjFmRmsGqk2a0WdPXKWZjtp-EvkUivpipP5eFkI4JooHDd56Bl5PRomqZarrI5PBFEV_mC8-HRi9E/s1600/56.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhneyfkTY4MQgQkOkJFxCEjX4tBF0_fOQJKchRqPN_Jfds5yBYBQZmxcV3TpOBrXJwtjFmRmsGqk2a0WdPXKWZjtp-EvkUivpipP5eFkI4JooHDd56Bl5PRomqZarrI5PBFEV_mC8-HRi9E/s1600/56.png" /></a></div>
<div align="center" class="MsoNormal" style="text-align: center;">
<br /></div>
<div class="MsoNormal">
Well… this was an internal
Dynamics 365 environment in which my account was a Domain Admin so I was a bit
confused but I played along. Went ahead and added my account in as a local
admin on the server and rebooted for good measure. That didn’t help. No matter
how much I restarted the router service, rebooted, tried adding permissions,
etc… it all fell on deaf ears. Googling the error message resulted in no
meaningful results – which usually means 1 of 2 things – my router is
completely hosed or I just uncovered a nice new bug with Dynamics 365!<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
After thinking about it for a
few more minutes, I figured why not try running it <i>AS AN ADMINISTRATOR!?!?! </i>Sure enough, 3 clicks later and I was in… Easy
workaround and I hope it saves some head-scratching! <o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEji4KlIvjRR_eamSgxpW0ndn1hvCu6CEiXP2i6N9zJQYnSctA_wfo7nhbrLLpJfpbqyjLuVPL2nSzg-vtFFzqI6LKDHKhYBBJDFrJi9vp9jju1NhWSqEsLYGsxFD15IlQMb-xlJp5fD-g7u/s1600/57.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEji4KlIvjRR_eamSgxpW0ndn1hvCu6CEiXP2i6N9zJQYnSctA_wfo7nhbrLLpJfpbqyjLuVPL2nSzg-vtFFzqI6LKDHKhYBBJDFrJi9vp9jju1NhWSqEsLYGsxFD15IlQMb-xlJp5fD-g7u/s1600/57.png" /></a></div>
<div class="MsoNormal">
<br /></div>
<br />
Gagehttp://www.blogger.com/profile/06440235801891990171noreply@blogger.com10Gainesville, FL, USA29.6516344 -82.32482619999996129.4309209 -82.647549699999956 29.872347899999998 -82.002102699999966tag:blogger.com,1999:blog-5336844806027714065.post-31044290058333036062017-03-28T18:22:00.000-04:002017-04-26T13:26:19.156-04:00Yet Another ADFS Looping Issue<div class="MsoNormal">
I recently applied the Dynamics
365 Update to a CRM 2016 Service Pack 1 environment that was setup for IFD and
ran into some unexpected behavior. This environment had about 15 organization
setup in it. When trying to log on using the external URLs (e.g.
orgname.domain.com) access worked without issue but using the internal URL for
any organization (e.g. crm.domain.com/orgname) CRM and ADFS would run in a
continuous loop. Sometimes it would error out, sometimes it would just keep
looping forever.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Started off by checking event
viewers on both the CRM and ADFS server. I noticed that on the times it did
error out after a few loops instead of looping nonstop, it resulted in an event
log similar to one I saw before caused by a bug with the 0.1 Update for CRM
2016 (<a href="http://blog.gagepennisi.com/2016/04/crm-2016-update-01-bug-with-adfs-for.html">http://blog.gagepennisi.com/2016/04/crm-2016-update-01-bug-with-adfs-for.html</a>):<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<i>MSIS7042: The same client browser session has made '6'
requests in the last '17' seconds. Contact your administrator for details.<o:p></o:p></i></div>
<div class="MsoNormal">
<i><br /></i></div>
<div class="MsoNormal">
So immediately I thought “Great,
here we go again.” There was also nothing in the CRM event viewer.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Hours of trying different different
troubleshooting tactics for similar situations (including this one with the
same looping behavior but with the external URL - <a href="http://blog.gagepennisi.com/2016/01/adfs-logon-page-loop-issue.html">http://blog.gagepennisi.com/2016/01/adfs-logon-page-loop-issue.html</a>)
yielded nothing. Rebuilt the Relying Party Trusts, reconfigured IFD, created a
self-signed certificate to verify it wasn’t a certificate issue, etc…<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Instead of keeping on with
the guess and check, I realized I needed to get more information around the
problem so I started with a Fiddler trace – great web debugging tool, if you
haven’t heard of it (<a href="http://www.telerik.com/fiddler">http://www.telerik.com/fiddler</a>).
Unfortunately, in this case all it did was confirm the behavior I was seeing in
the browser which was a constant redirect between D365 and ADFS.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjbd_QbUlB87d2h7g1pfQA7tym2wFBgF7B_6x3qB6FV0bMCjpkTW1alJQDGaYKN4dnvcl_IBWYabaJFvwkBJCl7lO86-E9fnPg7iDiXkcuK0N4_cHljPOe67_EzLn2MuSx3Mh6wiTi6bgPA/s1600/58.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjbd_QbUlB87d2h7g1pfQA7tym2wFBgF7B_6x3qB6FV0bMCjpkTW1alJQDGaYKN4dnvcl_IBWYabaJFvwkBJCl7lO86-E9fnPg7iDiXkcuK0N4_cHljPOe67_EzLn2MuSx3Mh6wiTi6bgPA/s1600/58.png" /></a></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
After that, I decided to run
a platform trace on the CRM server to see if CRM would give me any insight but
nothing really stood out to me. Almost at my wit’s end, I decided to rope in my
colleague Dan Francis to get another set of eyes on it. After some review of
the platform trace he noticed one little line that seemed a bit odd:<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<i>>Multi-org sharable cache loading system and
non-system metadata with build number 7.0.0.3543 and language 1033<o:p></o:p></i></div>
<div class="MsoNormal">
<i><br /></i></div>
<div class="MsoNormal">
CRM 2016 is version 8.0 and
D365 is 8.2 so the fact that we were seeing any refernce to 7.0.X.XXXX (CRM
2015) was not inline with what was to be expected. We checked the Deployment
Manger and realized there was an old, disabled organization from CRM 2015 that
was not upgraded (because it was disabled at the time of the original CRM 2016
upgrade). After some deliberation, we decided to remove that organization from
the deployment and boom! The internal URL began working as expected!<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Basically what we were able
to surmise from this is that when the internal URL is being used, all
organizations – whether enabled or disabled – are checked for versioning and
the lowest build number is used to load this “multi-org sharable cache” and
apparently D365 doesn’t play nicely with older versions hanging around. Moral
of the story – update/upgrade all of your orgs or just remove them.<o:p></o:p><br />
<br />
Big thanks to Dan the Man!</div>
Gagehttp://www.blogger.com/profile/06440235801891990171noreply@blogger.com0Gainesville, FL, USA29.6516344 -82.32482619999996129.4309209 -82.647549699999956 29.872347899999998 -82.002102699999966tag:blogger.com,1999:blog-5336844806027714065.post-11765592925510330812017-01-27T16:52:00.002-05:002017-01-27T16:52:47.900-05:00CRM and TLS 1.0While performing a routine installation of CRM 2016, I stumbled upon a new error during the system checks at the end of CRM installation wizard. The error was for the SQL Server check and read:<br />
<br />
<i>Could not connect to the following SQL Server: 'XXXXXX-SQL02'. Verify that the server is up and running and that you have SQL Server administrative credentials. [DBNETLIB][ConnectionOpen (SECDoClientHandshake()).]SSL Security error.</i><br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhvS-eFDHT8pj1vIRRtZh-TnIkFGV7Cd3Qfgbp6sGFrIxNRk3fIEFqMeXHcqb8Jp3nQ_e6qWRis6G7VnJhZQB8dC8sTngfw4qnKiD1HAyccOIWT6q8XN3tl2C9Jlig5SAwCA-RYAo9X3KXB/s1600/54.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhvS-eFDHT8pj1vIRRtZh-TnIkFGV7Cd3Qfgbp6sGFrIxNRk3fIEFqMeXHcqb8Jp3nQ_e6qWRis6G7VnJhZQB8dC8sTngfw4qnKiD1HAyccOIWT6q8XN3tl2C9Jlig5SAwCA-RYAo9X3KXB/s1600/54.png" /></a></div>
<br />
Having never seen this particular error, I resorted to my friend Google who led me down a wormhole or possible issues and resolutions related to certificates and protocols. Turns out that this was indeed related to a security protocol – TLS 1.0 to be exact. It was disabled on the SQL Server as part of our new security template for new servers. So with the help of one of Cloud Application Engineers, Spencer Ashworth, we enabled TLS 1.0. This is done through a simple registry change.<br />
<br />
Browse to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server\ and locate the DWORD named Enabled. Set the value to 1, close the registry and then reboot the server.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj7XD9ENw-2Vh-yRZvHosFpA7nLO1zHOXhJq4HjRETtegG8i9dbWKItosoXvvnBvWbKTkS_T0HC4UDHFZkc3_O3Ij4Va8fpgpVPa7FOlyPAgtBSlNRkcWZW8SMgrHbtltY7IYVZ6iodJbEi/s1600/55.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj7XD9ENw-2Vh-yRZvHosFpA7nLO1zHOXhJq4HjRETtegG8i9dbWKItosoXvvnBvWbKTkS_T0HC4UDHFZkc3_O3Ij4Va8fpgpVPa7FOlyPAgtBSlNRkcWZW8SMgrHbtltY7IYVZ6iodJbEi/s1600/55.png" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
Following the reboot and re-run of the CRM installation wizard, the system checks all passed and CRM was able to be successfully installed. Big thanks to Spencer who was the one that recalled CRM’s requirement of TLS 1.0 and knew the resolution!<br />
<div>
<br /></div>
Gagehttp://www.blogger.com/profile/06440235801891990171noreply@blogger.com1Gainesville, FL, USA29.6516344 -82.32482619999996129.4309209 -82.647549699999956 29.872347899999998 -82.002102699999966tag:blogger.com,1999:blog-5336844806027714065.post-73461816788884108662017-01-12T18:11:00.002-05:002017-01-12T18:12:47.073-05:00CRM Diagnostics Page<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="MsoNormal">
When troubleshooting CRM performance issues everyone
typically wants to point fingers at the servers – whether it be SQL, CRM, or
even SSRS – but a commonly overlooked factor is the network. Not known to
everyone is a tool built into CRM called the CRM Diagnostics Page. It is
basically a very simple way to check network performance. To access the CRM
Diagnostics Page simply go to:<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
http(s)://<YourCRMServerURL>/tools/diagnostics/diag.aspx<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
This will land you at a page that looks like the following:<o:p></o:p></div>
<div>
<br /></div>
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg5v77KG4bopQRewrAQtGQNzaEdYVvnw1jN0GgMBP_TJTxXgmfet3AyWEDQPQ21DbYbDLipsFOjLnLBuaZBevHHlPkw30N1wSvOyLqk_XzSV4wdOOgZyZf4AzpPFtvp-kkBN39olCiuWrc0/s1600/53.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em; text-align: center;"><img border="0" height="569" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg5v77KG4bopQRewrAQtGQNzaEdYVvnw1jN0GgMBP_TJTxXgmfet3AyWEDQPQ21DbYbDLipsFOjLnLBuaZBevHHlPkw30N1wSvOyLqk_XzSV4wdOOgZyZf4AzpPFtvp-kkBN39olCiuWrc0/s640/53.png" width="640" /></a><br />
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
On this page, you can clearly see the series of tests
available but what are they?<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
1. Latency Test<o:p></o:p></div>
<div class="MsoNormal">
This calculates the average time taken to download a small
text file 20 times. The file downloaded from the CRM server is
/_static/Tools/Diagnostics/smallfile.txt. CRM is designed to work best with
latency under 150 milliseconds. Latency can be a huge factor in performance for
offices far away the CRM server’s location.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
2. Bandwidth Test<o:p></o:p></div>
<div class="MsoNormal">
The bandwidth test downloads image files and records the
speeds. The recorded speeds are averaged together and provided in the results
summary. Bandwidth should ideally be higher than 50 KB/sec. This test, along
with the Latency Test, are the most helpful on this page.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
3. Browser Info<o:p></o:p></div>
<div class="MsoNormal">
This is a JavaScript pull of the local browser details such
as browser name, version, cookie status, operating system and the user-agent
string.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
4. IP Address<o:p></o:p></div>
<div class="MsoNormal">
This is the IP address of the client computer as known to
the server. The IP address is server-side dynamic and represents the IP address
which was used to contact the server.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
5. JavaScript tests<o:p></o:p></div>
<div class="MsoNormal">
The series of JavaScript tests times loops and returns their
execution time. They are essentially just memory/CPU stress tests on the client
machine. <o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
6. Organization Info<o:p></o:p></div>
<div class="MsoNormal">
Provides general server information- organization name, time
on server and client and URL.</div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Bonus! </div>
<div class="MsoNormal">
This is also a neat little secret: http(s)://<YourCRMServerURL>/home/home_debug.aspx.</div>
<div class="MsoNormal">
It has some of the same information as the diagnostics page - Not overly helpful but can possibly come in handy troubleshooting. I find it just to be a nice, concise page for deployment information to help with documentation.</div>
Gagehttp://www.blogger.com/profile/06440235801891990171noreply@blogger.com0Gainesville, FL, USA29.6516344 -82.32482619999996129.4309209 -82.647549699999956 29.872347899999998 -82.002102699999966tag:blogger.com,1999:blog-5336844806027714065.post-64110953301610119202016-12-02T07:04:00.000-05:002016-12-02T11:12:34.040-05:00HTTP to HTTPS Redirect for CRM using Claims-Based Authentication and IFDIn some cases, our customers would like HTTP to HTTPS redirection setup for CRM when using Claims-Based Authentication and IFD. There are a number of articles and blogs out on the internet that use various methods to accomplish this (e.g. URL Rewriting) but I find that a lot are overly complicated if all you are looking to do is have the redirect functioning internally (you do not want port 80 open on your firewall anyways). Below is what I perceive to be the easiest method to achieving this – using the HTTP Redirection capabilities of IIS:<br />
<br />
1.<span class="Apple-tab-span" style="white-space: pre;"> </span>First we will need to install HTTP Redirection on the CRM Web Server if it is not installed already. In Server Manager, go to Add Roles and Features and choose to add the HTTP Redirection feature under the Web Server role.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiYdqbNE4nFU3k5tGlmhJrHT4wbTHoDJhUGeCv1bPVnM0815pS2614PzwduFq99uSLxkGWs7071Zu0Fk4O8lb9xLPAAwLMRkGskItBURzA0WD59a4HrQBy7vcUDF6XyQcGR0iU6p7w5UAkz/s1600/45.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiYdqbNE4nFU3k5tGlmhJrHT4wbTHoDJhUGeCv1bPVnM0815pS2614PzwduFq99uSLxkGWs7071Zu0Fk4O8lb9xLPAAwLMRkGskItBURzA0WD59a4HrQBy7vcUDF6XyQcGR0iU6p7w5UAkz/s1600/45.png" /></a></div>
<br />
2.<span class="Apple-tab-span" style="white-space: pre;"> </span>Create two folders in a directory that you know will not be deleted. Name these folders something along the lines of “CRM Internal Redirect” and “CRM External Redirect”. Folder names and paths aren’t too important but in my example I just put them in the inetpub directory.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgjaTma_fXDA_pCXDtZe67qWU6Bv_HU6UdobertwNjqnCXt-wQbyjzHjYYmcQon0MycCRp95uZSIlq1M_oIOG-L3PMgIXt7y3Lq9Jze8oi1ug3VUpbVcw7-Hr43cNnaLUTO2OE3m3AqrE_B/s1600/46.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgjaTma_fXDA_pCXDtZe67qWU6Bv_HU6UdobertwNjqnCXt-wQbyjzHjYYmcQon0MycCRp95uZSIlq1M_oIOG-L3PMgIXt7y3Lq9Jze8oi1ug3VUpbVcw7-Hr43cNnaLUTO2OE3m3AqrE_B/s1600/46.png" /></a></div>
<br />
3.<span class="Apple-tab-span" style="white-space: pre;"> </span>Next, go into IIS. Make sure to remove the HTTP (port 80) binding from the CRM site before proceeding with the next steps.<br />
<br />
4.<span class="Apple-tab-span" style="white-space: pre;"> </span>Since two URLs can be used to be accessed CRM when it is setup for Claims and IFD, we will need to create the redirects for both URLs. Begin by creating a new website in IIS for the Internal URL.<br />
<ul>
<li>Site Name: Something descriptive such as “CRM Internal Redirect”</li>
<li>Physical Path: Browse to the CRM Internal Redirect folder created in step 2.</li>
<li>Binding Type: HTTP</li>
<li>IP Address: Unless you have multiple IP addresses on your server, you can leave this on All Unassigned. Otherwise, select the IP address used by CRM.</li>
<li>Port: 80</li>
<li>Host Name: This will your internal CRM URL which was configured when setting up Claims/IFD. If you are unsure of it, open the CRM Deployment Manager and go to properties. Select the Web Addresses tab and you should see your internal URL.</li>
</ul>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgUF_7oL3mBVgSe6NP2gC_a_1UPvd7Ep-rn_nojXFGtdXyGcyEkav2-_SojDX9sqamdBwpmFDsbopEP38JJqW6IG99qT6XVMQTmQZfcU2kGfQ5Zqm4-k8sFWVQ3q13G3n3l6dkKVW45cnoW/s1600/47.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgUF_7oL3mBVgSe6NP2gC_a_1UPvd7Ep-rn_nojXFGtdXyGcyEkav2-_SojDX9sqamdBwpmFDsbopEP38JJqW6IG99qT6XVMQTmQZfcU2kGfQ5Zqm4-k8sFWVQ3q13G3n3l6dkKVW45cnoW/s1600/47.png" /></a></div>
<br />
5.<span class="Apple-tab-span" style="white-space: pre;"> </span>Just like step 4, create another new site in IIS – this time for the external URL:<br />
<ul>
<li>Site Name: Something descriptive such as “CRM External Redirect”</li>
<li>Physical Path: Browse to the CRM External Redirect folder created in step 2.</li>
<li>Binding Type: HTTP</li>
<li>IP Address: Unless you have multiple IP addresses on your server, you can leave this on All Unassigned. Otherwise, select the IP address used by CRM.</li>
<li>Port: 80</li>
<li>Host Name: This will your exteransl CRM URL which was configured when setting up Claims/IFD. If you are unsure of it, this is the unique name of your CRM organization followed by the domain (e.g. orgname.domain.com).</li>
</ul>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgEk_FBhz6BxTClVXvqXQypyoVmThWsW9QNN-pjxfN-QE4wdu-gkU38Fl7K9A9O9ZW8hSOhlTOc0vJy4LF5LbAM0cuun7xEw9wj94rWmy4KBzYia_xkecFgYtHYsYxJYKMwBXqKVZIY9UCJ/s1600/48.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgEk_FBhz6BxTClVXvqXQypyoVmThWsW9QNN-pjxfN-QE4wdu-gkU38Fl7K9A9O9ZW8hSOhlTOc0vJy4LF5LbAM0cuun7xEw9wj94rWmy4KBzYia_xkecFgYtHYsYxJYKMwBXqKVZIY9UCJ/s1600/48.png" /></a></div>
<br />
6.<span class="Apple-tab-span" style="white-space: pre;"> </span>You should now have IIS looking similar to this:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgTSo6VrAREeme4NjU27p3zXyyvuA8p61oXqwnR9sHW7vNkr2T5hTNTSjOpelOQZCoaVPWs_AHMMuzBoDwEXz0a554xDF9is3856mSrb6UDpSXQYcXMEMEwl5zMNteGZXG7pAMZEqh6aLXk/s1600/49.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgTSo6VrAREeme4NjU27p3zXyyvuA8p61oXqwnR9sHW7vNkr2T5hTNTSjOpelOQZCoaVPWs_AHMMuzBoDwEXz0a554xDF9is3856mSrb6UDpSXQYcXMEMEwl5zMNteGZXG7pAMZEqh6aLXk/s1600/49.png" /></a></div>
<br />
7.<span class="Apple-tab-span" style="white-space: pre;"> </span>Click on your Internal Redirect site and open the HTTP Redirect module:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi1l2R32raUfwKgxbhgeXUqgYpeBwazANgnfniulvV9bxpKCsE-LiMxJmqoH-VJriY7R7OdNKm98e-yICjRe0xjW_9Q2WbxaJKZcnC_0znBzmq28Tf574VW_R5n1bomigU16a0dNSNrtYb9/s1600/50.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi1l2R32raUfwKgxbhgeXUqgYpeBwazANgnfniulvV9bxpKCsE-LiMxJmqoH-VJriY7R7OdNKm98e-yICjRe0xjW_9Q2WbxaJKZcnC_0znBzmq28Tf574VW_R5n1bomigU16a0dNSNrtYb9/s1600/50.png" /></a></div>
<br />
8.<span class="Apple-tab-span" style="white-space: pre;"> </span>In the HTTP Redirect settings, check the box for “Redirect requests to this destination:” and then enter your internal URL with HTTPS:// prefixed. Leave the other boxes unchecked and status code at 302. Apply the configuration.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj9vrdO_iinknlr9n4J4ur-3nDR8qY0sySDR4-NRZBGCk0_Xo7VeZn_kb7q7mMRQzDhGrrofxOHO7UVYHykZjR0CcyL9n9tpokhZm82_q9UWqJQQVfsE4691EXKXwcqcAcM9wGyIsXJ0Wfn/s1600/51.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj9vrdO_iinknlr9n4J4ur-3nDR8qY0sySDR4-NRZBGCk0_Xo7VeZn_kb7q7mMRQzDhGrrofxOHO7UVYHykZjR0CcyL9n9tpokhZm82_q9UWqJQQVfsE4691EXKXwcqcAcM9wGyIsXJ0Wfn/s1600/51.png" /></a></div>
<br />
9.<span class="Apple-tab-span" style="white-space: pre;"> </span>Now do the same for the External redirect site. Click on your External Redirect site and open the HTTP Redirect module. In the HTTP Redirect settings, check the box for “Redirect requests to this destination:” and then enter your external URL with HTTPS:// prefixed. Leave the other boxes unchecked and status code at 302. Apply the configuration.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhY_4B0zW8MVM6YvBI6qOouoN_Huy2ibGZ468c0SsFoD47jcyS8FsYUXlboFhkbr_NwEZ8IKJC12JOusgzLCvFYlTCv7M6rPRlI-fu7MzxR2RHbC0LO4L_WZWZwGRPRXpJj6kbj1y7Y7lM-/s1600/52.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhY_4B0zW8MVM6YvBI6qOouoN_Huy2ibGZ468c0SsFoD47jcyS8FsYUXlboFhkbr_NwEZ8IKJC12JOusgzLCvFYlTCv7M6rPRlI-fu7MzxR2RHbC0LO4L_WZWZwGRPRXpJj6kbj1y7Y7lM-/s1600/52.png" /></a></div>
<br />
That’s it. You should now be able to enter either of the CRM URLs with HTTP into a browser and have it redirected to HTTPS appropriately.<br />
<div>
<br /></div>
Gagehttp://www.blogger.com/profile/06440235801891990171noreply@blogger.com2Gainesville, FL, USA29.6516344 -82.32482619999996129.4309209 -82.647549699999956 29.872347899999998 -82.002102699999966tag:blogger.com,1999:blog-5336844806027714065.post-69021772351991960772016-11-08T20:30:00.000-05:002016-11-09T11:59:53.022-05:00Insufficient Winsock Resources Available to Complete Socket Connection InitiationSeemingly out of the blue, one of our customers could no longer log in to their CRM. As it appeared to be an authentication issue, I began troubleshooting on their ADFS server. Upon opening the ADFS Management Console, I was greeted with the following error message:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg8eW3LawRXpIzTdqG-8B9TDSrp3TLeLLr_AWfeRZlIdrnHwQfFApUTdlsr3FsSpsea4DjYt6SmRA9R4xsPHXP3wXep_-lbiXyoa4dz7LT-6ZZrzMYIxhsWiRtxz4x70RBXPII1gpd0Rr5j/s1600/44.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg8eW3LawRXpIzTdqG-8B9TDSrp3TLeLLr_AWfeRZlIdrnHwQfFApUTdlsr3FsSpsea4DjYt6SmRA9R4xsPHXP3wXep_-lbiXyoa4dz7LT-6ZZrzMYIxhsWiRtxz4x70RBXPII1gpd0Rr5j/s1600/44.png" /></a></div>
<br />
In the event viewer were a number of errors similar to this:<br />
<br />
<i>Microsoft.IdentityServer.Configuration.ReadServiceConfigFailedException: MSIS2001: Configuration service URL is not configured. ---> System.InsufficientMemoryException: Insufficient winsock resources available to complete socket connection initiation. ---> System.Net.Sockets.SocketException: An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full 127.0.0.1:1500</i><br />
<br />
Well, this was a new one for me but at least the error message actually gave a description instead of something generic. Logic dictates that if there isn’t enough of something, give it more. In this case, it appeared to me that ADFS was complaining about not having enough ephemeral ports so I figured I would increase the number available.<br />
<br />
<ol>
<li>Start Registry Editor.</li>
<li>Locate the following subkey in the registry, and then click Parameters: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters</li>
<li>On the Edit menu, click New, and then add the following registry entry:<br />Value Type: DWORD<br />Value Name: MaxUserPort<br />Value Data: 65534 (decimal)</li>
<li>Reboot server</li>
</ol>
After completing the above, ADFS was able to open the connection to its database and users were able to log back in to CRM. Now, it may be worthwhile to investigate exactly why ports suddenly became busy… perhaps there is a socket leak or new applications were installed… but this should at least get you up and running in the meantime.<br />
<div>
<br /></div>
Gagehttp://www.blogger.com/profile/06440235801891990171noreply@blogger.com0Gainesville, FL, USA29.6516344 -82.32482619999996129.4309209 -82.647549699999956 29.872347899999998 -82.002102699999966tag:blogger.com,1999:blog-5336844806027714065.post-23286112486723609102016-11-03T13:38:00.001-04:002016-11-03T13:38:58.413-04:00Calling LoadLibraryEx on ISAPI filter DefaultAddonFilter.dll failedI recently had an interesting issue with a client’s CRM 2011 to 2016 go-live. Following all of my upgrade work and initial testing, I typically like to reboot the CRM and SQL servers and then test again. In this particular instance, when the servers came back online I tested CRM again only to receive a lovely error message from Internet Explorer:<br />
<br />
<i>HTTP Error 500.0 – Internal Server Error</i><br />
<i><br /></i>
<i>Calling LoadLibraryEx on ISAPI filter C:\Program Files\Microsoft Dynamics CRM\Server\bin\DefaultAddonFilter.dll failed.</i><br />
<br />
After a fair amount of digging I noticed that the Visual C++ 2013 Redistributable (64-bit) was not present in the add/remove programs list on the CRM server. It seemingly uninstalled itself during the reboot because otherwise I would have had this issue pre-reboot. So, I went out and grabbed the installer package for Visual C++ 2013 Redistributable (64-bit) from MS (<a href="http://go.microsoft.com/fwlink/p/?LinkId=402059">http://go.microsoft.com/fwlink/p/?LinkId=402059</a>) and reinstalled it. After that and an IISReset, CRM began functioning as normal and everything retested everything successfully.<br />
<br />
Unfortunately, I am at a loss as to why this happened – perhaps something to do with server patching. Also of note is that the redistributable did not remove itself from the SQL server.<br />
<br />Gagehttp://www.blogger.com/profile/06440235801891990171noreply@blogger.com2Gainesville, FL, USA29.6516344 -82.32482619999996129.4309209 -82.647549699999956 29.872347899999998 -82.002102699999966tag:blogger.com,1999:blog-5336844806027714065.post-64736783962675716312016-10-21T15:54:00.001-04:002016-10-21T15:54:10.477-04:00Reports in CRM not working - The type initializer for 'Microsoft.Crm.LocatorService' threw an exception.We had a customer running into an issue while trying to run reports from CRM. Of course, the error in the CRM UI was the usual rsProcessingAborted error - Cannot create a connection to Data Source. So as I always need to do, I dug into the SSRS logs. The errors I could extract from there were:<br />
<br />
<i>Microsoft.Crm.Reporting.DataExtensionShim.Common.ReportExecutionException: The type initializer for 'Microsoft.Crm.LocatorService' threw an exception. ---> </i><br />
<i><br /></i>
<i>Microsoft.Crm.Reporting.DataExtensionShim.Common.ReportExecutionException: Cannot load Counter Name data because an invalid index 'W3SVC_W3WP' was read from the registry.</i><br />
<br />
From what I could surmise, there was something wrong with the performance counters on the server(s). I did find that Microsoft does have a KB for this error but it is in reference to update rollups on the CRM Outlook Client. Luckily for me, the fix turned out to be similar!<br />
<br />
<ol>
<li>On the CRM Server, open an administrative command prompt.</li>
<li>Type “lodctr /r” and press enter.</li>
<li>You will then get the message ‘Info: Successfully rebuilt performance counter setting from system backup store’.</li>
<li>Restart CRM Services and run an IISReset</li>
<li>On the SSRS Server, open an administrative command prompt.</li>
<li>Type “lodctr /r” and press enter.</li>
<li>You will then get the message ‘Info: Successfully rebuilt performance counter setting from system backup store’.</li>
<li>Restart SSRS Services.</li>
</ol>
<br />
After following the above process, reports in CRM began working again. The commands run rebuild the performance counters.<br />
<div>
<br /></div>
Gagehttp://www.blogger.com/profile/06440235801891990171noreply@blogger.com1Gainesville, FL, USA29.6516344 -82.32482619999996129.4309209 -82.647549699999956 29.872347899999998 -82.002102699999966tag:blogger.com,1999:blog-5336844806027714065.post-17415815860976353782016-09-02T14:55:00.001-04:002016-09-02T14:55:34.646-04:00An attempt was made to access a socket in a way forbidden by its access permissionsWhen setting up the Microsoft Dynamics Email Router, there can be a lot of obstacles in getting emails to send and receive properly. One of which turns out to be McAfee VirusScan. If you get the following error when testing the connection on the Outgoing profile, you may want to see if McAfee (or any other virus protection software) is running on the server:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhzQrLRBogJWEme950PpKEsS2DbaT1plUOSuR72uS7BuTQGFJ8KkxZFJgy1RVvEidwVvRpxNo0rrfzWW3yXIyUBu5o0ltFZJZOQ_yMwWYYf1emJA04AHE3naO_SUYYiOIs37Kl6ZQcYvEn9/s1600/39.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhzQrLRBogJWEme950PpKEsS2DbaT1plUOSuR72uS7BuTQGFJ8KkxZFJgy1RVvEidwVvRpxNo0rrfzWW3yXIyUBu5o0ltFZJZOQ_yMwWYYf1emJA04AHE3naO_SUYYiOIs37Kl6ZQcYvEn9/s1600/39.png" /></a></div>
<br />
<i>Outgoing Status: Failure – An error occurred while checking the connection to the email server {smtp server name}. An attempt was made to access a socket in a way forbidden by its access permissions.</i><br />
<br />
In order to fix this, right click on the McAfee icon in the system tray and open up the VirusScan Console.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiH3eT5rgwUqU576gOOqGfC2WhekgmeBW_YXCPArnHZ0NRbhA2aKWOzBN5sqfPvZ70IPLZovUQvwgEMw_NBd7tR3c_26HjT_DjZ12ZsWt79n-MbICcpM9kWBQF4zgMlzPAoB51m2pQxuz8F/s1600/40.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiH3eT5rgwUqU576gOOqGfC2WhekgmeBW_YXCPArnHZ0NRbhA2aKWOzBN5sqfPvZ70IPLZovUQvwgEMw_NBd7tR3c_26HjT_DjZ12ZsWt79n-MbICcpM9kWBQF4zgMlzPAoB51m2pQxuz8F/s1600/40.png" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
In the VirusScan Console, double-click “Access Protection”.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjxTjzQD8ApDijkHyp8-Mo4oFrbeEUm5wjpcywwItnIQ58xmn0gXq1eniLgivS3MmQ5f4HXTKzilbmraMXRV2qrMAekcJTtDZiYUvPK2Cd9o7ZSi-jeDVCvxTHCUSUrij4z8stavbJIR60L/s1600/41.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjxTjzQD8ApDijkHyp8-Mo4oFrbeEUm5wjpcywwItnIQ58xmn0gXq1eniLgivS3MmQ5f4HXTKzilbmraMXRV2qrMAekcJTtDZiYUvPK2Cd9o7ZSi-jeDVCvxTHCUSUrij4z8stavbJIR60L/s1600/41.png" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
Under Categories, click on “Anti-virus Standard Protection” and then check to see if there are any checkmarks next to “Prevent mass mailing worms from sending mail”. If there are, simply uncheck them.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgsC16uzl7gx0ovhJeMo1ZjHX99fsx9jiQza_5DlpbVdFe6li5o6eIJ3k9HtAAoGd7GHqQPLF5Ts9rpkbqd5ULGa2fJBTdUL1DKSbbWmrLnzov2XQJhuU0bE_7w3ZlLWdGBW3OHBIR9UDIL/s1600/42.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgsC16uzl7gx0ovhJeMo1ZjHX99fsx9jiQza_5DlpbVdFe6li5o6eIJ3k9HtAAoGd7GHqQPLF5Ts9rpkbqd5ULGa2fJBTdUL1DKSbbWmrLnzov2XQJhuU0bE_7w3ZlLWdGBW3OHBIR9UDIL/s1600/42.png" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
Click OK and close out of the VirusScan Console. Open the email router and try testing again. You should now be seeing green!<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhIBqdYILg-iTWeRTaI8x6ofEdtlk9fSF-dOAqUVoMtlxpAQXHPmGkFK6e4DcoY0dH0OZ6Rvo9u9Y16RuR88gccZ97s4cRy25BUYdWs_rSugzvpZwUo6mtHP9X5oplYrSfBMRPBeSQxLTH7/s1600/43.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhIBqdYILg-iTWeRTaI8x6ofEdtlk9fSF-dOAqUVoMtlxpAQXHPmGkFK6e4DcoY0dH0OZ6Rvo9u9Y16RuR88gccZ97s4cRy25BUYdWs_rSugzvpZwUo6mtHP9X5oplYrSfBMRPBeSQxLTH7/s1600/43.png" /></a></div>
<div>
<br /></div>
Gagehttp://www.blogger.com/profile/06440235801891990171noreply@blogger.com0Gainesville, FL, USA29.6516344 -82.32482619999996129.4309209 -82.647549699999956 29.872347899999998 -82.002102699999966tag:blogger.com,1999:blog-5336844806027714065.post-90879240828721213812016-08-04T12:30:00.001-04:002016-08-04T12:34:53.701-04:00Report Server cannot load the SQLPDW extensionWhile troubleshooting SSRS issues, you may run into the following error messages in logs and traces:<br />
<br />
<i>Report Server (MSSQLSERVER) cannot load the SQLPDW extension.</i><br />
<i><br /></i>
<i>Report Server (MSSQLSERVER) cannot load the TERADATA extension.</i><br />
<i><br /></i>
On numerous occasions I have seen both customers and colleagues believe that these errors were the source of their problems. After which, the wild goose chase to resolve these errors ensues. I am here to tell you that it is highly unlikely that they are related to your problem at hand (especially if you are only using SSRS for CRM reporting).<br />
<br />
These errors occur because the Teradata and SQLPDW extensions are registered in the Reporting Services configuration file by default but the assemblies for these extensions do not get installed in the same manner. Typically these extensions are used with big data and business analytics.<br />
<br />
If the errors do not bother you, simply ignore them and track down other error messages. However, if you are the type that prefers clean logs you can take the following steps to alleviate the error messages from being logged:<br />
<ul>
<li>Open the rsreportserver.config file. This can usually be found in \Program Files\Microsoft SQL Server\MSRSXX_X.MSSQLSERVER\Reporting Services\ReportServer.</li>
<li>In this config file, simply search for and comment out the entries related to SQLPDW and TERADATA. There should be 2 entries for SQLPDW and 3 for TERADATA. Below is an example:</li>
</ul>
<div>
<i><!--Extension Name="SQLPDW" Type="Microsoft.ReportingServices.DataExtensions.SqlDwConnectionWrapper,Microsoft.ReportingServices.DataExtensions"/--></i></div>
<div>
<div>
<i><br /></i></div>
<div>
<i><!--Extension Name="SQLPDW" Type="Microsoft.ReportingServices.SemanticQueryEngine.Sql.MSSQLADW.MSSqlAdwSQCommand,Microsoft.ReportingServices.SemanticQueryEngine"></i></div>
<div>
<i> <Configuration></i></div>
<div>
<i> <EnableMathOpCasting>False</EnableMathOpCasting></i></div>
<div>
<i> </Configuration></i></div>
<div>
<i></Extension--></i></div>
</div>
<div>
<i><br /></i></div>
<div>
<div style="font-style: italic;">
<!--Extension Name="TERADATA" Type="Microsoft.ReportingServices.DataExtensions.TeradataConnectionWrapper,Microsoft.ReportingServices.DataExtensions"/--></div>
<div style="font-style: italic;">
<br /></div>
<div style="font-style: italic;">
<!--Extension Name="TERADATA" Type="Microsoft.ReportingServices.SemanticQueryEngine.Sql.Teradata.TdSqlSQCommand,Microsoft.ReportingServices.SemanticQueryEngine"></div>
<div style="font-style: italic;">
<Configuration></div>
<div style="font-style: italic;">
<EnableMathOpCasting>True</EnableMathOpCasting></div>
<div style="font-style: italic;">
<ReplaceFunctionName>oREPLACE</ReplaceFunctionName></div>
<div style="font-style: italic;">
</Configuration></div>
<div style="font-style: italic;">
</Extension--></div>
<div style="font-style: italic;">
<br /></div>
<div style="font-style: italic;">
<!--Extension Name="TERADATA" Type="Microsoft.ReportingServices.SemanticQueryEngine.Sql.Teradata.TdSqlModelGenerator,Microsoft.ReportingServices.SemanticQueryEngine"/--></div>
<div>
<ul>
<li><div style="display: inline !important;">
Save and close the config file.</div>
</li>
<li><div style="display: inline !important;">
Restart the SSRS service.</div>
</li>
</ul>
<div>
<br /></div>
</div>
</div>
Gagehttp://www.blogger.com/profile/06440235801891990171noreply@blogger.com0Gainesville, FL, USA29.6516344 -82.32482619999996129.4309209 -82.647549699999956 29.872347899999998 -82.002102699999966tag:blogger.com,1999:blog-5336844806027714065.post-20305938373100919012016-07-16T12:03:00.000-04:002016-08-08T11:35:58.993-04:00The private key does not support the exchange KeySpec.When using Active Directory Federation Services (ADFS) for claims-based authentication with Dynamics CRM, one of the requirements is a SSL certificate. If a new certificate has to be procured, it is imperative to make sure the certificate request (CSR) is being generated with the correct KeySpec, if required.<br />
<br />
There are two options for KeySpec:<br />
<ul>
<li>“1” or “XCN_AT_KEYEXCHANGE” </li>
<li>“2” or “XCN_AT_SIGNATURE”</li>
</ul>
<div>
With ADFS, the certificate needs to support key exchange so the required KeySpec is "1" or "XCN_AT_KEYEXCHANGE". If the other option is chosen, you may end up with failures when trying to log in to CRM and will see errors in the event viewer on the ADFS server similar to below.</div>
<div>
<i><br /></i></div>
<div>
<div>
<i>Exception type: NotSupportedException </i></div>
<div>
<i> Exception message: The private key does not support the exchange KeySpec.</i></div>
<div>
<i> at System.IdentityModel.Tokens.X509AsymmetricSecurityKey.DecryptKey(String algorithm, Byte[] keyData)</i></div>
<div>
<i> at System.IdentityModel.Selectors.SecurityTokenResolver.SimpleTokenResolver.TryResolveSecurityKeyCore(SecurityKeyIdentifierClause keyIdentifierClause, SecurityKey& key)</i><br />
<i><br /></i>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh6-J52rJMvhJaJy21eXpWHfavXmL1DgadY8UaTKvcqigTbV7qrwdkRL1OIJoqOrLLRCeyb_2bOsUo44CKU2UZS3prwJLNgBz57dF2-VYwOQslDxHTv5y30mtZJhIlRQcU3F5Hc9_sNzo_D/s1600/38.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="366" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh6-J52rJMvhJaJy21eXpWHfavXmL1DgadY8UaTKvcqigTbV7qrwdkRL1OIJoqOrLLRCeyb_2bOsUo44CKU2UZS3prwJLNgBz57dF2-VYwOQslDxHTv5y30mtZJhIlRQcU3F5Hc9_sNzo_D/s640/38.png" width="640" /></a></div>
<i><br /></i></div>
</div>
<div>
<br /></div>
<div>
While the certificate will still appear valid using "XCN_AT_SIGNATURE" and will secure the webpages, authentication will not succeed with ADFS so the certificate will need to be regenerated. </div>
Gagehttp://www.blogger.com/profile/06440235801891990171noreply@blogger.com0Gainesville, FL, USA29.6516344 -82.32482619999996129.4309209 -82.647549699999956 29.872347899999998 -82.002102699999966tag:blogger.com,1999:blog-5336844806027714065.post-82201987862667169542016-05-26T08:08:00.001-04:002016-05-26T08:08:55.307-04:00CRM Reporting Issue - The system cannot contact a domain controller to service the authentication requestHad a case come into my queue indicating a client’s reports in their production CRM were not working so I logged in and began taking a look. At first glance, I was seeing the generic “Reporting Error – The report cannot be displayed. (rsProcessingAborted)” that we see for 90% of reporting issues so I proceeded to the SSRS logs where I was greeted with the following error:<br />
<br />
<i>System.Runtime.InteropServices.COMException: The system cannot contact a domain controller to service the authentication request. Please try again later. (Exception from HRESULT: 0x80090350) ---> Microsoft.Crm.Reporting.DataExtensionShim.Common.ReportExecutionException: The system cannot contact a domain controller to service the authentication request. Please try again later. (Exception from HRESULT: 0x80090350)</i><br />
<br />
Interesting to say the least and something I had never seen before. My inclination was that a domain controller was down or somehow the connection to AD was severed (but then again, how was I able to log on the server). I ran a set command to check the logon sever and was able to ping it fine, along with all of the other DCs. Next stop was at the DNS/Gateway settings on the NIC – compared everything to another SQL/SSRS server that was working fine. Again, nothing seemed out of place.<br />
Off to the handy dandy event viewer! Immediately I noticed a flood of errors indicating that the automatic backups and log shipping were failing. Amidst those errors I found a familiar message:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjHF2pCBok2528N3je_wR-K3dqx-GDW7rycu2k8cO7Te71tnILzdlw_lyHzCJLLqb2sGydOccHFCAA_U-FMWMcaVpHm3qoAkW1_IsLZQxJXNLwuMuWBxj4_j6R9mDk7KarRTSQoBZDKQyuY/s1600/35.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjHF2pCBok2528N3je_wR-K3dqx-GDW7rycu2k8cO7Te71tnILzdlw_lyHzCJLLqb2sGydOccHFCAA_U-FMWMcaVpHm3qoAkW1_IsLZQxJXNLwuMuWBxj4_j6R9mDk7KarRTSQoBZDKQyuY/s1600/35.png" /></a></div>
<br />
Whatever was causing the reporting issue was also causing the backups to fail. I made my way through the events until I reached the beginning of the flood and there it was, in all its glory:<br />
<div class="separator" style="clear: both; text-align: center;">
<i><br /></i></div>
<i>BackupDiskFile::CreateMedia: Backup device '\\goxsaXXXX\D$\MSSQL11.XXXX\MSSQL\Backup\Log_Shipping\XXXX_20160524043001.trn' failed to create. Operating system error 1331(This user can't sign in because this account is currently disabled.).</i><br />
<div>
<br /></div>
<div>
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi6ZCS8SsqYNFn2oYezstcd6_UILDgDh7nWn7rkMjuAsVy5paGqFK0f05yYE4XWrKtznHrqiGw0vz9kOvO5QdAWjbI_-_G1eN6DRuIQDiPjpDLPrGT90wqL_AqP8_Y2kpU5C4AxVpIkMdNm/s1600/36.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em; text-align: center;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi6ZCS8SsqYNFn2oYezstcd6_UILDgDh7nWn7rkMjuAsVy5paGqFK0f05yYE4XWrKtznHrqiGw0vz9kOvO5QdAWjbI_-_G1eN6DRuIQDiPjpDLPrGT90wqL_AqP8_Y2kpU5C4AxVpIkMdNm/s1600/36.png" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div>
<div>
Easy enough – the SQLAdmin account running SSRS (and the other SQL services) cannot authenticate because it’s disabled.</div>
<div>
<br /></div>
<div>
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjJ5Md0qNUCvaXYXZFH_ist6gZs1sZ_GT0vwtvp2-vBt6U2Gcbj1v4j3pGGoilsAW5Yk3zbwbVXuRWdCQqKO-07b6qGd3Z-hhTb9B2d6x8vSlI2322-TX-GI_dMEHmM0Ac75NnBDiO3GNpc/s1600/37.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em; text-align: center;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjJ5Md0qNUCvaXYXZFH_ist6gZs1sZ_GT0vwtvp2-vBt6U2Gcbj1v4j3pGGoilsAW5Yk3zbwbVXuRWdCQqKO-07b6qGd3Z-hhTb9B2d6x8vSlI2322-TX-GI_dMEHmM0Ac75NnBDiO3GNpc/s1600/37.png" /></a></div>
<div>
</div>
<div>
Had the customer check AD and sure enough, the account was disabled. Once enabled, reports began working again. </div>
<div>
<br /></div>
<div>
In all, this was a very strange error message for the actual issue. It could have really led us on a wild goose chase into the networking side of things. Probably saved 2-3 hours by reading through the error logs and being thorough in investigation before going back to the customer with the wrong answer. Moral of the story: do your homework.</div>
</div>
<div>
<br /></div>
<div>
<br /></div>
Gagehttp://www.blogger.com/profile/06440235801891990171noreply@blogger.com3Gainesville, FL, USA29.6516344 -82.32482619999996129.4309209 -82.647549699999956 29.872347899999998 -82.002102699999966tag:blogger.com,1999:blog-5336844806027714065.post-73976845072417101072016-05-14T12:19:00.000-04:002016-05-14T12:19:02.535-04:00Use SSL for Outgoing Connection / Incoming Connection Radio Buttons Greyed Out for CRM Server Side Sync POP3-SMTP ProfileIf you need to create a Server Side Sync profile for your POP3 and/or SMTP servers without using SSL for your on-premise CRM 2013, 2015, or 2016 environments you may notice that you are unable to change the option to not use SSL. The radio buttons are simply greyed out and stuck set to “Yes”. This can be problematic if you want to run over basic HTTP.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhDfaKtNMNMcRi4GDVZfLCH6gI4SGqYcNmMVVU0hNGUzf52BaojZYsLQHp2s_LWjl5m2Qz6bZredI1-RKieZHt0veUUnJcXrAGjzGyOUY8su1w4HofhdBAzKXuhTeXSUs1VptbpNqCVdMbF/s1600/33.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhDfaKtNMNMcRi4GDVZfLCH6gI4SGqYcNmMVVU0hNGUzf52BaojZYsLQHp2s_LWjl5m2Qz6bZredI1-RKieZHt0veUUnJcXrAGjzGyOUY8su1w4HofhdBAzKXuhTeXSUs1VptbpNqCVdMbF/s1600/33.png" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
Luckily, these buttons can be enabled via the following PowerShell commands run on the CRM server:<br />
<br />
<i>Add-PSSnapin Microsoft.Crm.Powershell</i><br />
<i>$setting=Get-CrmSetting ServerSideSyncEmailSettings</i><br />
<i>$setting.AllowNonSSLEmail=$True</i><br />
<i>Set-CrmSetting $setting</i><br />
<i>Get-CrmSetting -SettingType ServerSideSyncEmailsettings</i><br />
<i>Exit</i><br />
<br />
After the commands are complete, refresh your browser and the buttons should now be active.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEivPVzodtlC3xGfsRh1xElkDWZDqXfNV6MiP7dTLRd-F7S7Jg6p_mES1wT5I5l1fqvMK61YBk1QQvt7p8DWAJFVHAI7uE45o2OScCwkjvTpnqEKdB8MigUqwt_uEq6cwUPwZ2ETkRUkxz37/s1600/34.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em; text-align: center;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEivPVzodtlC3xGfsRh1xElkDWZDqXfNV6MiP7dTLRd-F7S7Jg6p_mES1wT5I5l1fqvMK61YBk1QQvt7p8DWAJFVHAI7uE45o2OScCwkjvTpnqEKdB8MigUqwt_uEq6cwUPwZ2ETkRUkxz37/s1600/34.png" /></a></div>
Gagehttp://www.blogger.com/profile/06440235801891990171noreply@blogger.com0Gainesville, FL, USA29.6516344 -82.32482619999996129.4309209 -82.647549699999956 29.872347899999998 -82.002102699999966tag:blogger.com,1999:blog-5336844806027714065.post-77546518952264296182016-05-05T20:32:00.000-04:002016-05-06T12:11:07.619-04:00A Server Certificate Could Not Be Validated for URL - SQL Server Reporting Services 2012 <br />
If you ever get the following error during the system checks of the CRM installer, check to see if you can even access the Report Manager URL from the SSRS server:<br />
<br />
<i>A Server Certificate Could Not Be Validated for URL: http://reportservername/ReportServer </i><br />
<i><br /></i>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiHtbqHdDxboYrOnXSMWIHHnCCDC5fGQD-q1v1RohT21b9SGj1uxIjdwuWzEOGRA_GGgfIuc7vKjKzqf9DVEaRB2gst0TNckBkwQHm2iowpDguhTUFXaGBQ_0JdETNttM24j0c0KQn3i_PO/s1600/27.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiHtbqHdDxboYrOnXSMWIHHnCCDC5fGQD-q1v1RohT21b9SGj1uxIjdwuWzEOGRA_GGgfIuc7vKjKzqf9DVEaRB2gst0TNckBkwQHm2iowpDguhTUFXaGBQ_0JdETNttM24j0c0KQn3i_PO/s1600/27.png" /></a></div>
<br />
When checking the Report Manager URL (http://reportservername/Reports) using HTTP - not HTTPS - you may see the following error:<br />
<br />
<i>The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.</i><br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg_PmwzvatJ79mMHtnsXpNkKNhkd28k2XwYHiTqx0g_Q07HGXD2O8Cnl6pbBPBOJfHx8pb5kKfyf3ZCqDjLpLxcKVOGpPxdDz8p7N0rySNvSoyqABa1S0p4qyDfG8jUY4O8lGiqqGdOEpcP/s1600/28.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg_PmwzvatJ79mMHtnsXpNkKNhkd28k2XwYHiTqx0g_Q07HGXD2O8Cnl6pbBPBOJfHx8pb5kKfyf3ZCqDjLpLxcKVOGpPxdDz8p7N0rySNvSoyqABa1S0p4qyDfG8jUY4O8lGiqqGdOEpcP/s1600/28.png" /></a></div>
<br />
You will probably also get a certificate error accessing the Report Service URL (http://reportservername/ReportServer) which will end up resulting in a 404 error screen if you proceed. So why is SSRS looking for SSL/TLS when using HTTP?<br />
<br />
The answer is rather simple – it’s configured to do so. Here is how to change that:<br />
<br />
1.<span class="Apple-tab-span" style="white-space: pre;"> </span>Go to the Report Server directory. Typically it is {Drive}:\MSRS11\Reporting Services\ReportServer<br />
<br />
2.<span class="Apple-tab-span" style="white-space: pre;"> </span>Open the rsreportserver.xml file in notepad or other editing software.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg2vYiEHmzegF6gnTTq_xdHuT9feaa1KVLU5m9ksD4mMarIVY4ol0yaYPUCLc9zoi8qOFrWA2AZy7Hs-3d-HUjHZB1NSGbDJ5Vcsn_Jg1JODBPNhL4HHnsXDE_rw1C3AcwPagQtZyXrrRza/s1600/29.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg2vYiEHmzegF6gnTTq_xdHuT9feaa1KVLU5m9ksD4mMarIVY4ol0yaYPUCLc9zoi8qOFrWA2AZy7Hs-3d-HUjHZB1NSGbDJ5Vcsn_Jg1JODBPNhL4HHnsXDE_rw1C3AcwPagQtZyXrrRza/s1600/29.png" /></a></div>
<br />
3.<span class="Apple-tab-span" style="white-space: pre;"> </span>In this configuration file, look for or run a find for SecureConnectionLevel. It should be about 12 lines from the top. You will likely see this key set to a value of 2.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh41aiI2gvOGvB37DHHqSS_P4gKt4T_r0ANApzn54yJP4Et1hnaD0eff1pMyAGa1x5poYcMJjvikM3UaTxHJUbDuNH4jgn1AdnEKfU1PDqHuSg8DK4gi-tIo2wm-W5lOdE9v4wYF6F1fZQL/s1600/30.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh41aiI2gvOGvB37DHHqSS_P4gKt4T_r0ANApzn54yJP4Et1hnaD0eff1pMyAGa1x5poYcMJjvikM3UaTxHJUbDuNH4jgn1AdnEKfU1PDqHuSg8DK4gi-tIo2wm-W5lOdE9v4wYF6F1fZQL/s1600/30.png" /></a></div>
<br />
4.<span class="Apple-tab-span" style="white-space: pre;"> </span>Change the value to 0 so that the line reads:<br />
<Add Key=”SecureConnectionLevel” Value=”0” /><br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgOAy0GvCLdewzmwn8B4IJsk-FH13sRnGDxo4ey86LrL7-A2duKGn__CfbQdwirxj3q45iYUfZmPnthn7FtdeeGZVwAonWBgE7nJb3NIuTmsCE5UG58b5N2SXwRiwWgMnNZ6zZiCs8eztJK/s1600/31.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgOAy0GvCLdewzmwn8B4IJsk-FH13sRnGDxo4ey86LrL7-A2duKGn__CfbQdwirxj3q45iYUfZmPnthn7FtdeeGZVwAonWBgE7nJb3NIuTmsCE5UG58b5N2SXwRiwWgMnNZ6zZiCs8eztJK/s1600/31.png" /></a></div>
<br />
5.<span class="Apple-tab-span" style="white-space: pre;"> </span>Save and close the file. Restart the SQL Reporting Services service and try accessing the Report Manager URL once more. You should now get the site as expected over HTTP.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEico_jS1OJcLQro2X4HsF3_Pq38uYpv2w3Ty4o8yMW0RG0MgHB-7FkS4KQfO5NSxPnGlQUl0PgAmv7Ri60gIn9ftIEp1pi2cAbAgZW6r6bpw9ia9H8dWlaTXs3UEHCsQymEstuYH905WsNM/s1600/32.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEico_jS1OJcLQro2X4HsF3_Pq38uYpv2w3Ty4o8yMW0RG0MgHB-7FkS4KQfO5NSxPnGlQUl0PgAmv7Ri60gIn9ftIEp1pi2cAbAgZW6r6bpw9ia9H8dWlaTXs3UEHCsQymEstuYH905WsNM/s1600/32.png" /></a></div>
<br />
6.<span class="Apple-tab-span" style="white-space: pre;"> </span>Go back to your CRM server and re-run the installation wizard.<br />
<br />
Of course, the alternative to going this route is to actually provide SSRS with an SSL certificate and access it over HTTPS only but some may not want the added hassle or cost.<br />
<br />Gagehttp://www.blogger.com/profile/06440235801891990171noreply@blogger.com0Gainesville, FL, USA29.6516344 -82.32482619999996129.4309209 -82.647549699999956 29.872347899999998 -82.002102699999966tag:blogger.com,1999:blog-5336844806027714065.post-17180147052228825872016-04-24T09:30:00.000-04:002016-05-06T12:11:14.657-04:00CRM and IIS Machine KeysWhen you have multiple CRM web (front-end) servers splitting the load, requests can bounce between servers or they can be set to remain on the same server through the NLB/Firewall settings. The latter option is commonly referred to as “Sticky Sessions” or “Persistence”.<br />
<br />
If requests bounce between servers (whether by design or by fault), you may notice issues when accessing certain functionality within CRM. Often it will be accompanied by the following error message in the event viewer:<br />
<br />
<i>Event code: 3012 </i><br />
<i>Event message: An error occurred processing a web or script resource request. The resource identifier failed to decrypt. </i><br />
<i><br /></i>
<i>Exception information: </i><br />
<i> Exception type: HttpException </i><br />
<i> Exception message: Unable to validate data.</i><br />
<i> at System.Web.Configuration.MachineKeySection.EncryptOrDecryptData(Boolean fEncrypt, Byte[] buf, Byte[] modifier, Int32 start, Int32 length, Boolean useValidationSymAlgo, Boolean useLegacyMode, IVType ivType, Boolean signData)</i><br />
<i> at System.Web.UI.Page.DecryptString(String s, Purpose purpose)</i><br />
<i> at System.Web.Handlers.ScriptResourceHandler.ProcessRequest(HttpContextBase context, VirtualFileReader fileReader, Action`2 logAction, Boolean validatePath)</i><br />
<br />
Basically what is happening is one server encrypted (validated) some of the traffic with an automatically generated key and another server received it but cannot decrypt it because it has different keys. These keys are known as “machine keys” and are found within IIS. By default, these keys are all set to generate automatically and no two are the same. When you are using multiple web servers, the machine keys need to be set statically and shared amongst them. Here is how to do this, starting on the first web server:<br />
<br />
<ol>
<li>Open IIS, select the Microsoft Dynamics CRM Website, and double-click “Machine Key”<br /><br /><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEifEAfxoMWCdEWW-tghAsgPadYCCwWxZzK9-prRs4_IzKwxVpzuWSaqHe0iGzwkPNewPstN_VTqC-l1oo3vNbo4HXpXXENqOBcZ-Vusb4Uxrn3VnOrE6fJNQ7Y9lkgGx0wEMFy6bIy4Rzte/s1600/22.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em; text-align: center;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEifEAfxoMWCdEWW-tghAsgPadYCCwWxZzK9-prRs4_IzKwxVpzuWSaqHe0iGzwkPNewPstN_VTqC-l1oo3vNbo4HXpXXENqOBcZ-Vusb4Uxrn3VnOrE6fJNQ7Y9lkgGx0wEMFy6bIy4Rzte/s1600/22.png" /></a></li>
<li>Uncheck the “Automatically generate at runtime” and “Generate a unique key for each application” boxes under both “Validation Key” and “Decryption Key”.<br /><br /><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiWjHohJW1KOWi3acPBBDFwb1iHae3EBxCN7N2SCLCCb7xt5CSagwHrM7Ef3-TDmmelEpoHIO6s-CgR7vdDHjGzVzzYRsksqLbwr3laLTBrF3dO5Ut0alK9AxJia2zK5Tyb-C-_YnNSPcN-/s1600/23.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em; text-align: center;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiWjHohJW1KOWi3acPBBDFwb1iHae3EBxCN7N2SCLCCb7xt5CSagwHrM7Ef3-TDmmelEpoHIO6s-CgR7vdDHjGzVzzYRsksqLbwr3laLTBrF3dO5Ut0alK9AxJia2zK5Tyb-C-_YnNSPcN-/s1600/23.png" /></a></li>
<li>Click “Generate Keys” on the right side of the screen.<br /><br /><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgMxaIAZAh3epUNJKStwl6YeWp6jad6zEZtUSiCawRF73xdpuDSucsoMTx88iSADqRjio19-HL0Rf1zVt3VUTebtK0RQ4Pv3zFR9rAvNCVM3fM1Ef6T_1xh1Z0y1iGMgK38EQDTflINx8qr/s1600/24.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em; text-align: center;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgMxaIAZAh3epUNJKStwl6YeWp6jad6zEZtUSiCawRF73xdpuDSucsoMTx88iSADqRjio19-HL0Rf1zVt3VUTebtK0RQ4Pv3zFR9rAvNCVM3fM1Ef6T_1xh1Z0y1iGMgK38EQDTflINx8qr/s1600/24.png" /></a></li>
<li>This will create new, random keys.<br /><br /><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjOFDLN9tECSjSPUKRCcjMqEc0BOx3ogSB99c71ja9jSWx3ZcKBwXbtpSjxFtlXT_z7lqonWbpH6U1PhU7285TA2mUxjJU7Q2utpKISfnXqERuW-c33Gb9sibh9mklajlvS10f1SpjaOCg9/s1600/25.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em; text-align: center;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjOFDLN9tECSjSPUKRCcjMqEc0BOx3ogSB99c71ja9jSWx3ZcKBwXbtpSjxFtlXT_z7lqonWbpH6U1PhU7285TA2mUxjJU7Q2utpKISfnXqERuW-c33Gb9sibh9mklajlvS10f1SpjaOCg9/s1600/25.png" /></a></li>
<li>Click apply.<br /><br /><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgMxaIAZAh3epUNJKStwl6YeWp6jad6zEZtUSiCawRF73xdpuDSucsoMTx88iSADqRjio19-HL0Rf1zVt3VUTebtK0RQ4Pv3zFR9rAvNCVM3fM1Ef6T_1xh1Z0y1iGMgK38EQDTflINx8qr/s1600/24.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em; text-align: center;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgMxaIAZAh3epUNJKStwl6YeWp6jad6zEZtUSiCawRF73xdpuDSucsoMTx88iSADqRjio19-HL0Rf1zVt3VUTebtK0RQ4Pv3zFR9rAvNCVM3fM1Ef6T_1xh1Z0y1iGMgK38EQDTflINx8qr/s1600/24.png" /></a></li>
<li>From here, repeat steps 1 and 2 on the remaining web servers. Instead of generating new keys as in step 3, copy and paste the keys generated from earlier into the remaining servers so that all servers have the same set of keys.</li>
<li>Once keys on all servers are set and applied, reset IIS on all the boxes. That should do it.</li>
</ol>
Gagehttp://www.blogger.com/profile/06440235801891990171noreply@blogger.com5Gainesville, FL, USA29.6516344 -82.32482619999996129.4309209 -82.647549699999956 29.872347899999998 -82.002102699999966tag:blogger.com,1999:blog-5336844806027714065.post-52762761267500067952016-04-15T14:52:00.000-04:002016-08-04T12:08:48.119-04:00CRM 2016 Update 0.1 Bug with ADFS for Server 2012 R2<br />
Following a successful upgrade to CRM 2016 and installation of the 0.1 Update, users could no longer authenticate against ADFS using the “internal” URL. <br />
<br />
On the ADFS server I was seeing Event ID 364 in the Event Viewer:<br />
<br />
<i>Exception details:</i><br />
<i>Microsoft.IdentityServer.Web.InvalidRequestException: MSIS7042: The same client browser session has made '6' requests in the last '0' seconds. Contact your administrator for details.</i><br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj0LLUxynfj9402WbbpHNiYqxvBe0yQdv9BRynK-Ib9cEd8FzqCi8pWnCuuh9PViayHQ-vLUwXCcrcVvMLQG9Ms0oTpdIzeyirVXegSSnsUGsbu37YjRj40AyAYTO9oMnqUctfLhIAbd9T-/s1600/21.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj0LLUxynfj9402WbbpHNiYqxvBe0yQdv9BRynK-Ib9cEd8FzqCi8pWnCuuh9PViayHQ-vLUwXCcrcVvMLQG9Ms0oTpdIzeyirVXegSSnsUGsbu37YjRj40AyAYTO9oMnqUctfLhIAbd9T-/s1600/21.png" /></a></div>
<br />
In efforts to get this working, I tried completely re-configuring CRM for claims and IFD and even recreated the Relying Party Trusts. All with no luck but apparently, I was not alone on this issue and Microsoft has acknowledged it as a bug with Update 0.1. The following forum thread has more info:<br />
<br />
<a href="https://social.msdn.microsoft.com/Forums/windowsserver/en-US/9d4040eb-81fa-4144-ae4b-85ca4610aa1d/crm-2016-problem-with-claimsbased-authentication?forum=crm">https://social.msdn.microsoft.com/Forums/windowsserver/en-US/9d4040eb-81fa-4144-ae4b-85ca4610aa1d/crm-2016-problem-with-claimsbased-authentication?forum=crm</a><br />
<br />
These are the only real details on this issue currently available:<br />
<br />
<i>There were major code changes in Ara UR1 for authentication. The affected code is in Microsoft.Crm.Core.Security.Identity.IdentityExtensions.GetUserPrincipalName(). We are unable to cast from type ClaimsIdentity to a new type CrmIdentity. Therefore, the variable is null, and we cannot retrieve the information.</i><br />
<br />
Please note that only the ‘internal’ URL is affected when IFD is setup. The ‘external’ URL (e.g. https://orgname.domain.com) that uses forms authentication works fine still. I will update this blog post as more information becomes available.<br />
<br />
UPDATE: Service Pack 1 for CRM 2016 resolves this issue.<br />
<br />Gagehttp://www.blogger.com/profile/06440235801891990171noreply@blogger.com0Gainesville, FL, USA29.6516344 -82.32482619999996129.4309209 -82.647549699999956 29.872347899999998 -82.002102699999966tag:blogger.com,1999:blog-5336844806027714065.post-29166033887072720632016-04-03T19:56:00.002-04:002016-05-06T12:11:26.494-04:00Host Header Configured on Selected Site Does Not Resolve to an IP Address that is Assigned to the Local System.I was recently performing an in-place upgrade from CRM 2015 to CRM 2016 when during the system checks I received the following warning:<br />
<br />
<i>Host Header "notCRM.domain.com" configured on selected site does not resolve to an IP address that is assigned to the local system. This conflict must be reconciled for CRM Server to function properly. </i><br />
<i><br /></i>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiYS-2G5iSUQ9C9eONBGTqlFKiwdCl9ruDohfpIS7nWKlKjYtE5eygyjtYtp6MDwlSSsP1OA910NXDiGjj_nDwqloXkQ45jNhWm1Odq9iScpmX6SnlmjNpN7nL8qsF5ArlWVbQSRJYjHKyi/s1600/15.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiYS-2G5iSUQ9C9eONBGTqlFKiwdCl9ruDohfpIS7nWKlKjYtE5eygyjtYtp6MDwlSSsP1OA910NXDiGjj_nDwqloXkQ45jNhWm1Odq9iScpmX6SnlmjNpN7nL8qsF5ArlWVbQSRJYjHKyi/s1600/15.png" /></a></div>
<br />
The fact that it was giving me a host header that did not pertain to the CRM website was odd so I took a look at IIS. What I discovered was that there was another website setup in IIS on the CRM Server. And that site had the site ID of 1.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiKy67tdhM1W5qFNPpLizUV7-bNvgtSdkiIKcwSTx1STdEYwiFQroB6WUaI3ThvJHJ9uivgVg4om9a1whDSk45fIk-6ANpi1XpL66m2AoRAl3E7QrhikK85UYsGO8zjM8gDsel-M-uDe7ZI/s1600/16.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiKy67tdhM1W5qFNPpLizUV7-bNvgtSdkiIKcwSTx1STdEYwiFQroB6WUaI3ThvJHJ9uivgVg4om9a1whDSk45fIk-6ANpi1XpL66m2AoRAl3E7QrhikK85UYsGO8zjM8gDsel-M-uDe7ZI/s1600/16.png" /></a></div>
<br />
As I was the original installer of CRM for this deployment, I knew that this site wasn’t here when CRM was installed. CRM originally had the site ID of 1, not this other site. Somebody had been in here messing around and changed the site IDs manually. After asking enough questions, I learned who did this and why. To make a long story short, their site needed to have the ID of 1. CRM, on the other hand, does not care so I rolled with the punches and decided I would work around this rather than cause a fuss.<br />
<br />
From what I could deduce about the error message, the CRM installer was being told to look at the IIS website that had an ID of 1 to perform the upgrade on. I decided to switch the CRM site back to the ID of 1. To do this, you must first change the other site’s ID to a number not in use (e.g. 3, in my case). To do this, go into the site’s advanced settings.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgF8xNMTU79aZPFj6LzZ4-kF7IbyA_OIHRBkxfaH4zlHyryBHL6uD65fVRjoWrevWr007-KHVOJidX8wNaGJhF8nGHkJMYdyf-5GKJaxbu7EUIREynqt69PnPV3Sd6gbkSa78DI4VQcPGt0/s1600/17.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgF8xNMTU79aZPFj6LzZ4-kF7IbyA_OIHRBkxfaH4zlHyryBHL6uD65fVRjoWrevWr007-KHVOJidX8wNaGJhF8nGHkJMYdyf-5GKJaxbu7EUIREynqt69PnPV3Sd6gbkSa78DI4VQcPGt0/s1600/17.png" /></a></div>
<br />
After the other site was changed, I reverted the CRM site back to 1 and reset IIS.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgApoNIrwyDF-bbl2wvBpHXCALWPZWJ7UBEEPZGypZhR1MsdsRG8e_BRVdki0uxP93REZNZG6WIdXtqKPfIka9-tAKsz_nnzqi-RfpcY08BmQDdiHsjy4SxOTWX9wAT8AHxVi4TTBs47DLN/s1600/18.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgApoNIrwyDF-bbl2wvBpHXCALWPZWJ7UBEEPZGypZhR1MsdsRG8e_BRVdki0uxP93REZNZG6WIdXtqKPfIka9-tAKsz_nnzqi-RfpcY08BmQDdiHsjy4SxOTWX9wAT8AHxVi4TTBs47DLN/s1600/18.png" /></a></div>
<br />
The upgrade wizard will need to be restarted for it to pick up the change but once you make it back to the system checks, the warning should be gone.<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiZYoupucBasv7nimEfezf-sqFo8Ji51-vkIis2tJUrWW1U1p9DJwb7bG8q4qu7HW1AzEwxrDfeOuvSnaySd5uka504IXRy7Su-U8hi4wHvfQaI2ghyphenhyphenXzLs0cwvuRkF9OiL82BFesBwHC7H/s1600/19.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiZYoupucBasv7nimEfezf-sqFo8Ji51-vkIis2tJUrWW1U1p9DJwb7bG8q4qu7HW1AzEwxrDfeOuvSnaySd5uka504IXRy7Su-U8hi4wHvfQaI2ghyphenhyphenXzLs0cwvuRkF9OiL82BFesBwHC7H/s1600/19.png" /></a></div>
<br />
The upgrade succeeded without issue but we weren’t done just yet. Since the other site needed to have the ID of 1, I needed to revert changes to the site IDs which in itself isn’t complicated. What was not taken into account was a registry key in HKLM\Software\Microsoft\MSCRM called “website”.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhlZx2l5jZhubii8T1HqOeAqzRCGDcUbhViEriKegoEfSuct5elw1Q0vW3Ji969Db25KTpIxkYR27MwVIpsAWSAgh49gfAgO2Iuk6qJX7RzWKtWuY7_j6PDXUFeULlCFv408nMF14bX03Cd/s1600/20.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhlZx2l5jZhubii8T1HqOeAqzRCGDcUbhViEriKegoEfSuct5elw1Q0vW3Ji969Db25KTpIxkYR27MwVIpsAWSAgh49gfAgO2Iuk6qJX7RzWKtWuY7_j6PDXUFeULlCFv408nMF14bX03Cd/s1600/20.png" /></a></div>
<br />
This registry key indicates which website directory in IIS CRM is using. Since CRM is using the ID of 2, this key needed to be switched to “LM/W3SVC/2”. In case you have been wondering what the ID controls, it is just an identifier used in the directory name for trace files and log files. It’s nothing critical that will not let CRM operate as normal.<br />
<br />
By now you are probably thinking “Why didn’t you change this key rather than switching the site IDs to resolve the warning message during the upgrade?!?!” Well... it didn’t occur to me until afterward I completed the upgrade. Hindsight is 20/20!Gagehttp://www.blogger.com/profile/06440235801891990171noreply@blogger.com0Gainesville, FL, USA29.6516344 -82.32482619999996129.4309209 -82.647549699999956 29.872347899999998 -82.002102699999966tag:blogger.com,1999:blog-5336844806027714065.post-35660617665990515022016-03-17T17:21:00.000-04:002016-03-17T17:22:24.772-04:00The Authentication Endpoint Username Was Not Found On The Configured Secure Token Service and Port 808While not recommended, circumstances sometime present the need to install CRM and ADFS on the same server. If this is done on Windows Server 2012 R2, you will likely run into issues connecting anything through the discovery service such as the Outlook Add-In, Email Router, and Plugin Registration Tool. The error will read:<br />
<br />
<i>The authentication endpoint Username was not found on the configured Secure Token Service.</i><br />
<br />
If taken literally, one would be tempted to go to the ADFS Configuration and enable the /adfs/services/trust/13/username endpoint as shown below:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhcI4LW_5IwP5TMpVDc3-tFNN3f-Q8jDdmqDuaTr315rS7U2WppG_q6gMDfiNGy0ocM0U7_6_ZYX83glN8e22M0Y009_e1ADRiGsqJamzYCDJ-uZZuiZnebOf0-0BywSoAqRa3aWW2600Xi/s1600/14.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhcI4LW_5IwP5TMpVDc3-tFNN3f-Q8jDdmqDuaTr315rS7U2WppG_q6gMDfiNGy0ocM0U7_6_ZYX83glN8e22M0Y009_e1ADRiGsqJamzYCDJ-uZZuiZnebOf0-0BywSoAqRa3aWW2600Xi/s1600/14.png" /></a></div>
<br />
DO NOT DO THIS! On the outside chance that it does actually fix the immediate issue it can cause further authentication problems and is NOT recommended – despite what some other blogs/forums may tell you.<br />
<br />
Further investigation should eventually lead you to this error in the ADFS event viewer logs:<br />
<br />
<i>System.ServiceModel.AddressAlreadyInUseException: There is already a listener on IP endpoint 0.0.0.0:808. This could happen if there is another application already listening on this endpoint or if you have multiple service endpoints in your service host with the same IP endpoint but with incompatible binding configurations. —> System.Net.Sockets.SocketException: Only one usage of each socket address (protocol/network address/port) is normally permitted</i><br />
<br />
With ADFS for Server 2012 R2, net.tcp port 808 is utilized for a function of the federation service. You may recall that port 808 is also used by CRM for its sandbox service so it’s easy to see the problem here. Port conflict! Luckily, the solution is rather simple. Just open a PowerShell prompt on the server and enter the following:<br />
<br />
<i>Set-ADFSProperties -nettcpport 809</i><br />
<br />
(Note: In the above the command, 809 is just an example of a port that can be used and is not required. If something else is running over port 809 on your server, substitute it for some other number.)<br />
<br />
After the command has been run, restart the ADFS service, IIS, and the email router service (if the email router was having the issue connecting) – to be on the safe side, you could just reboot the whole server. Give it another go and you should be in business! If you are wondering why this hasn’t been an issue with past versions of ADFS, it's because the federation services used to run on ports 1500 and 1501.<br />
<div>
<br /></div>
Gagehttp://www.blogger.com/profile/06440235801891990171noreply@blogger.com5Gainesville, FL, USA29.6516344 -82.32482619999996129.6516344 -82.324826199999961 29.6516344 -82.324826199999961