So I have been doing some ADFS 3.0 work as of late. Part of this work included getting CRM 2016 to use ADFS for authentication instead of the normal AD (IWA) approach. Getting the user side of it set up is not that hard, and there are many good sources for correct information. Now it turns out CRM has some hidden integration complexity. Though not directly from CRM itself, but the Connector for Microsoft Dynamics (which has not changed since CRM 2011). This was making a stink and would not connect to ADFS. At the time I did not know that the error was caused by the connector not being able to talk to ADFS server because of a firewall issue, so I wrongfully assumed that the error had something to do with ADFS configuration. This analysis was done on internal federation configuration and not using IDF (published external using ADFS Proxy), i.e using the Intranet configuration for the CRM RP with Windows Authentication only active.
I recently did some work on publishing internal legacy applications using WAP and ADFS for pre-authentication. Wrapping of the production part of these components I wanted to get full visibility into how they performed over time. To do this I added in SCOM management packs for both products. As monitoring kicked in I started seeing that the health of the overall ADFS farm always defaulted to a warning state. Delving a bit deeper into why, I found that it was the “MEX Endpoint Is Unreachable”-monitor that was keeping the farm in this state.
I always try not to have to do too much repeat work, so when I have some extra time I like to make some stuff easier. This time I threw together a quick and easy way of adding the needed firewall openings to servers for SCOM Agent push installs.
One little note; the commands used here are only present on 2012 R2 with PS 4.0 and newer servers.
$SCOMmgmtServers = @("IPscommgmtserver1","IPscommgmtserver2")
New-NetFirewallRule -DisplayName "SCOM Agent TCP" -Direction Inbound –Protocol TCP –LocalPort "5723" -Action allow -RemoteAddress $SCOMmgmtServers
New-NetFirewallRule -DisplayName "SCOM Agent Push Install TCP" -Direction Inbound –Protocol TCP –LocalPort @("135","139","445") -Action allow -RemoteAddress $SCOMmgmtServers
New-NetFirewallRule -DisplayName "SCOM Agent Push Install UDP" -Direction Inbound –Protocol UDP –LocalPort @("137","138") -Action allow -RemoteAddress $SCOMmgmtServers
New-NetFirewallRule -DisplayName "SCOM Agent Push Install RPC" -Direction Inbound -Program "%SystemRoot%\system32\svchost.exe" -RemoteAddress $SCOMmgmtServers -Protocol TCP -LocalPort RPC
I recently did some work with WAP 2012R2 (Web Application Proxy) and ADFS 3.0 (Active Directory Federation Services) looking into how the different timeout values work in conjunction with publishing internal legacy applications to the intrawebz. This using IWA (Integrated Windows Authentication) for the backend, and that meant setting up KCD (Kerberos Constrained Delegation) between WAP and the application servers. I will not focus on that configuration here. I am more interested in how the security mechanisms work, and how that impacts how to configure the different time constraint values for logon and session related parameters.
With lower tier VM’s in Azure you have a limit on how many data disk you can attach. As an example an A1 can only have 2 datadisks of 1 TB each attached. So if you just want to use Azure for storing a lot of data like backup you are kind of out of luck. You would either need to get a higher tier VM that allows for more datadisks or use a service like Azure Backup instead.
Let me give you one more option, Azure Files Shares.
Now, I hear a lot of you say; “you can’t use a share as a local disk”. And you would be correct, you can’t. Though let’s be a bit sneaky, and get around that limitation.
Just a small post so I can remember this to the next time.
If you want to get rid of the warning when using published applications with Remote App on Windows Server 2012 R2 you will need to configure the following.
On the server hosting your RD stuff, start server manager and find the remote desktop section. Check that the broker publisher has been configured with the correct certificate.
Set the GPO for your users to trust the certificate used for signing the remote apps. Just start gpedit.msc and find the entry displayed below under User Configuration.