Just a quick one to remind myself as I’m taking in some coffee.
If you need to get the set OU filters for the Azure AD Connector, this little Powershell snippet might help:
# Get-ADSyncConnector gets all connector and just find the name of the one you want to use
$ExcludeFilterFileName = "c:\temp\ExcludeFilter.txt"
$IncludeFilterFileName = "c:\temp\IncludeFilter.txt"
$ADConnectorName = "AD Connector Name"
$ADConnector = Get-ADSyncConnector -Name $ADConnectorName
# Assumes that only one partition exist on the connector
$ADConPartition = Get-ADSyncConnectorPartition -Connector $ADConnector -Identifier $ADConnector.Partitions.Identifier.Guid
$ADConPartition.ConnectorPartitionScope.ContainerInclusionList | Out-File -FilePath $IncludeFilterFileName
$ADConPartition.ConnectorPartitionScope.ContainerExclusionList | Out-File -FilePath $ExcludeFilterFileName
Does not seem a way to import as of yet though 🙁
Will update if I find a workaround for this.
I have been working a lot with Azure Automation lately. It’s a great product, helping organize the use of Powershell making an awesome language even better.
With AA as any other of the Azure services there are always some challenges, one is modules and how some keep ever changing…I’m looking at you AzureRM. This is why I wanted to get some automation into this process. And as it is in the product name this is only fitting.
Browsing the AA teams github I found the following Runbook that looked promising. Though in testing it has some issues with modules on gallery that did not use the same title as module name, like you know AzureAD. Therefore I did some fast triaging to get it into shape. As with everything, check to see if somebody else already have figured it out before creating the wheel anew. Browsing the web this guy had it all figured out, so I borrowed the code.
SCOM is a great product, but sometimes I would have liked that they spent a bit more time on implementing the silverlight dashboards, especially the performance one.
The reason? The usage of the hardcoded GUIDs to populate the performance counters.
Let’s back up a bit, before going on, and talk a bit about the usage scenario. Creating these dashboards using the GUI is fine, though if you need to create a lot of the same type of dashboards, just with different targets. The GUI route can become a big timesink. Also one usually want to keep these types of dashboards in an unsealed management pack so one can do adjustments as necessary on the fly without having to go the way through Visual Studio to seal the MP anew each time a change is needed. VS still has some complexity tied to it and not everybody wants to invest time into learning this tool.
I really like this script for sending SMS using SCOM. Though it has some bugs in it’s current form. I also do not have a Twilio account. That is why I decided to rewrite some of the logic to use generic HTTP SMS gateways. Currently it is set up for using pswincom sms gateway, though this can easily be changed to some other service. Though you will need to find out how to construct the URL for that service and change the code in the CreateSMSurl function to match.The PSWinCom details are here.
I really like this Wei Out there template, and also this that gives a overview of the Send Queue Size of the SCOM agent. Though I’m lazy and do not like that I have to click the performance counter column so it will sort by it. That is why I have added some code so it will, though you will lose the state column to the sorting logic. But I’m fine with that. I also added the option to only show the Top N highest values.
Here is the changed code:View the code on Gist.
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 the new DPM 2016 soon to be released there are some changes to the unattended file.
The old one for DPM 2012 R2 is below:
UserName = <A user with credentials to install DPM>
CompanyName = <Name of your company>
ProductKey = <The 25-character DPM product key in the format xxxxx-xxxxx-xxxxx-xxxxx-xxxxx>
# SqlAccountPassword = <The password to the DPM$ account>
# StandardAgentLicenses = <No. of standard agent licenses you have purchased>
# EnterpriseAgentLicenses = <No. of enterprise agent licenses you have purchased>
# ProgramFiles = C:\Program Files\Microsoft Data Protection Manager
# DatabaseFiles = C:\Program Files\Microsoft Data Protection Manager\DPM\DPMDB
# IntegratedInstallSource = <Location of the DPM setup files>
# ---For using a remote SQL Server instance ---
# YukonMachineName = <Name of the SQL Server computer> OR <SQL Cluster Name>
# YukonInstanceName = <Name of the instance of SQL Server that Setup must use>
# YukonMachineUserName = <User name that Setup must user>
# YukonMachinePassword = <Password for the user name Setup must use>
# YukonMachineDomainName = <Domain to which the SQL Server computer is attached>
# ---For using a reporting SQL Server instance in case of DPMDB in SQL Cluster ---
# ReportingMachineName = <Name of the SQL Server computer>
# ReportingInstanceName = <Name of the instance of SQL Server that Setup must use>
# ReportingMachineUserName = <User name that Setup must user>
# ReportingMachinePassword = <Password for the user name Setup must use>
# ReportingMachineDomainName = <Domain to which the SQL Server computer is attached>
The changes for DPM 2016 is that all the Yukon prefixed variables now have SQL before it. This makes much more logical sense. Also there still are some small bugs. If you use the ProgramFiles variable, the installer will at writing (TP 5), just append the value you put in the unattend file and then try to add the default path name on top of that. This will make the installer quit as the character length of the path string will exceed 64 character, which is not allowed.