This time I wanted to show a more comprehensive example from a real life need and how I went about solving it.
The challenge we faced was that we had previously set our Azure AD Connector to use the e-mail field in AD to be synced to Azure AD as the UPN. This would have been fine if not for that our need changed. As we matured in the use of cloud services we needed to also add some of our contractors to Azure AD. The problem was that in the local AD the email field was populated with the contractor’s actual email, and this would make the sync fail if the accounts were added.
For any automation tool, logging is pretty important. Though I would also say readability of the logs is something one should also think about when writing code.
The general consensus in AA for logging is that one should use:
as the accepted ways of moving information to the different log types. Here I want to focus on Write-Error, and how one can structure its use to get good readable logs in AA. In addition I will speak to handling error situations in general as an extension to this. Specific how I combine the use of try/catch and Write-Error flow in Runbooks I author.
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