Get Organization Unit (OU) Name - MS CRM 2011/2013/2015/2016/D365 On-Premise

Get Organization Unit (OU) Name MS CRM 2011/2013/2015/2016/D365 On-Premise - 

You may find the OU Name which you configured while installing CRM2011/2013/2015/2016/D365 On-Premise

On the CRM server (where you installed MSCRM2011/2013/2015/2016/D365 On-Premise)

Navigate to below path.

C:\Users\userID which you used to install CRM\AppData\Roaming\Microsoft\MSCRM\Logs\crmserversetup.log

open this file with notepad 

press Control+F

Find this word :   OUDistinguishedName

you will get the OU Name there in below format.

OU=OU NAME-OU,DC=your domain,DC=your domain,DC=com

The request failed. The request was aborted: Could not create SSL/TLS secure channel.

Error: The request was aborted: Could not create SSL/TLS secure channel.

Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Reason: The error is generic and there are many reasons why the SSL/TLS negotiation may fail. The most common is an invalid or expired server certificate, and you took care of that by providing your own server certificate validation hook, but is not necessarily the only reason. The server may require mutual authentication, it may be configured with a suites of ciphers not supported by your client, it may have a time drift too big for the handshake to succeed and many more reasons.

Solution: Added some more code to make it works -

ServicePointManager.Expect100Continue = true;
ServicePointManager.DefaultConnectionLimit = 9999;
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12 | SecurityProtocolType.Ssl3;

Windows Authentication Errors on local Servers

Windows Authentication Errors on local Servers (Loopback Protection)

Issue:

When logged into your Windows server, IIS Windows authentication through a browser does not work for either Windows Auth or Basic Auth using Windows user accounts. Login attempts just fail with a 401 error.

However, accessing the same site externally and logging in works just fine, using Windows log on credentials. It only fails when on the local machine.

Cause:

This problem is caused by a policy called Loopback Protection that is enabled on server OSs by default. Loopback Protection disables authenticating against local Windows accounts through HTTP and a Web browser.

Resolution:

Perform this configuration manually find this key in the registry on the server:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa

and edit or add a new key:

DisableLoopbackCheck (DWORD)

then sent the value to 1 to disable the loopback check (local authentication works), or to 0 (local authentication is not allowed).

Using PowerShell:

New-ItemProperty HKLM:\System\CurrentControlSet\Control\Lsa -Name "DisableLoopbackCheck" -Value "1" -PropertyType dword