1. I took a look at DRS but this looked find under Monitoring à Database Replication.
2. I decided to run Replication Link Analyser on each site locally with local admin permissions on SQL Server and the Site Server.  That returned nothing wrong on either site.
3. I then decided to ensure that my primary site could process the messages, so I walked through the various log files:

1. ddm.log (processes the incoming device registration and gives the initial basic information you see in the console)
2. dataldr.log (processes the incoming hardware inventory being sent by the service via the connector)
3. statsys.log (processes the incoming state messages sent by the service via the connector that gives information about device compliance and app deployment)
4. mpfdm.log (at the primary site processes and routes messages from the connector to components)
5. hman.log (at the CAS (if you have one) routes messages to each device’s assigned primary site for already enrolled clients or to the site configured in the Connector for new devices)

• All of the above checked out 100% and appeared as you’d expect on a normal site.

A.       For new devices: messages are sent to the site configured in the Intune Connector, and those devices then become assigned to that site.

B.       For already registered devices: messages for that device are sent to the site to which the device is registered. 

·         scheduler.log (schedules the transmission and ensure that sender scheduler currently allow communication)

·         sender.log (actually does SMB transmission)

At some point last year I had written a script to help with some internal work we were doing analysing status message occurances. We wanted a lookup table of status message strings that could be passed to folks who only had visibility of status message IDs and severity. We had old vbscripts that would do this, but they relied on a deprecated automation library from an older version of the SDK. When I asked some software engineers about this, they said that the library was based on some Win32 APIs. I set out to see if I could get those APIs working from PowerShell. :)

Generating status message strings is done using the FormatMessage function that is part of Win32 API. Generally function relies on a message table resource inside a DLL, a message ID and an array of insertion strings (placeholders). The function takes the MessageID looks it up in the tables inside the DLL, and then for each placeholder value inserts a string from the supplied string array.  It then return the completed string back to the caller. Configuration Manager has 3 such message table resource DLLs: srvmsgs.dll (site), provmsgs.dll (provider) and climmsgs.dll (client). If you'd like more information about these DLLs and status messages in Configuration Manager, see the CM SDK here: https://msdn.microsoft.com/en-us/library/jj218266.aspx & https://msdn.microsoft.com/en-us/library/jj218288.aspx.

The script uses a feature of .NET called PInvoke (Platform Invoke) that allows you to call out to unmanaged code and ultimately the underlying platform. Since PowerShell allows you to run .NET code inside of a script nicely, we can combine these two elements to enable us to call the FormatMessage function from PowerShell.  This is done by using the following example for FormatMessage:

$sigFormatMessage = @'
[DllImport("kernel32.dll")]
public static extern uint FormatMessage(uint flags, IntPtr source, uint messageId, uint langId, StringBuilder buffer, uint size, string[] arguments);
'@

We need three different function ultimately to get this working. A LoadLibrary and GetModuleHandle are required to load the DLL then get a handle that DLL to pass to FormatMessage.  Once we've got the PInvoke code snippets, we need to tell PowerShell to load these as references via an Add-Type call. Here is the PowerShell call for Format Message again:

$Win32FormatMessage = Add-Type -MemberDefinition $sigFormatMessage -name "Win32FormatMessage" -namespace Win32Functions -PassThru -Using System.Text

Once we have FormatMessage Win32 type declared in $Win32FormatMessage, we can call the FormatMessage function using the :: notation as follows:

$result = $Win32FormatMessage::FormatMessage($flags, $ptrModule, 1073741824 -bor $iMessageID, 0, $stringOutput, $sizeOfBuffer, $stringArrayInput)

You'll notice that the syntax of that last line looks weird. It looks weird because it isn't a .NET method call (and it certainly isn't any PowerShell like). This is because the Win32 API are C++ based, so we have to use the C++ syntax. The noticeable difference is that the output of the function is a return code integer and the string output is supplied as variable $stringOutput in the input to the function.  Without going into pointers and C++ syntax history (things best left to Computer Science courses) just accept that's the way it works. :)

You'll also notice that I'm using binary OR of 1073741824 with the Message ID.  The reason for this is that the status message ID in configuration manager are actually stored in our message resource DLLs as binary OR of their severity and status message ID. 1073741824 happens to be the integer value for Informational severity. 2147483648 is warning and 3221225472 is error if you're wondering.

That's the main/key parts to calling Win32 APIs via PowerShell for status message string matching. The script has additional logic to walk through the various permutations of status message IDs along with a bit of output and parameters. You can find the entire script here along with sample output for System Center 2012 R2 Configuration Manager here (xlsx).

Hopefully that provides you with a good explaination of how to get status message strings in PowerShell, and generally how to call Win32 API from PowerShell.

Special thanks to Sherry Kissinger and Michael Niehaus for nudging me and reminding me to post this. :)

Just re-introducing this blog. I'd actually forgotten about the fact I'd opened it 5 years ago. My team and I decided it would be better to have a team blog (The Manageability Guys, over at https://aka.ms/mgmtguys). Anyway, 5 years down the line and I've changed roles in Microsoft and joined the Enterprise Client and Mobility org in Microsoft (the org is responsible for Microsoft Intune, Configuration Manager and Azure RemoteApp among others), as part of their Customer Acceleration Team. I'll probably be posting in various blogs as well as this one...but this one will be focused on the more geeky side of things. :)

I hope you enjoy it.

Regards,
Saud

This is my first blog post so I thought I would make it something vaguely interesting (to certain people).  Powershell has been around for a while, though for most ConfigMgr people it remains a dark area.  This is primarily due to the lack of samples explaining how to access the ConfigMgr WMI Provider on a Site Server.  This post will walk you through the ConfigMgr SDK sample in VBScript and show a corresponding sample in Powershell. 

I’ve written up the following sample to walk you through the process of converting the ‘How to Create a Static  Collection’ sample in the SDK from C# or VBscript to Powershell.  The sample is designed to work locally on the site server with a site code of LAB, but establishing a connection to a remote provider should not prove too difficult.  We are using some of the .NET System.Management classes directly to give us direct access to WMI.  This makes things easier to maps back to C#/VBScript samples in the SDK.

The first thing we need to do, is instantiate an instance of the SMS_Collection class.

$collClass = [WMIClass] “root\SMS\Site_LAB:SMS_Collection”
$collInstance = $collClass.CreateInstance()

With that done, we can populate all settings required for our collection.

$collInstance.Name = “FooCollection1”
$collInstance.OwnedByThisSite = $true

You may want to set additional properties for this collection.  From there, we store our instance of the SMS_Collection class, and use the returned object to tell us the path of the new instance.  We will need this later on. To properly handle the Path property we need to cast the type of object returned using [WMI].

$collPath = $collInstance.Put()
$collection = [WMI] $collPath.Path

We now follow the same instantiation process used above to create an instance of SMS_CollectToSubCollect class.  The SMS_CollectToSubCollect class is required to tie our new collection to an existing collection so that is actually shows up in the console.  This can be any existing collection’s ID or the special ID of COLLROOT to appear under the ‘Collections’ node.  In our case, we are using COLLROOT for simplicities sake.

$subcollClass = [WMIClass] “root\SMS\Site_LAB:SMS_CollectToSubCollect”
$subcollInstance = $subcollClass.CreateInstance()

So we set our relationship class (SMS_CollectToSubCollect) parentCollectionID property to COLLROOT.  Again, this could be any existing collection ID.

      $subcollInstance.parentCollectionID = “COLLROOT”

We now need to link our relationship class’s subCollectionID property to our new collection’s ID.  Since this is assigned by the provider based on existing collection IDs, we much reference it using the new collection’s object’s CollectionID property and store the new instance of SMS_CollectToSubCollect, as such:

$subcollInstance.subCollectionID = $collection.CollectionID
$subcollection = $subcollInstance.Put()

Now that we have a new collection linked to the ‘Collections’ root node, we ought to put something in there, so let’s create a direct membership rule for a computer called ‘Test’.  We follow the same WMI connection process using the [WMIClass] cast and then instantiate SMS_CollectionRuleDirect. We also set the ResourceClassName property to “SMS_R_System” to let ConfigMgr know that we want to find System resources.

$directruleClass = [WMIClass] “root\SMS\Site_LAB:SMS_CollectionRuleDirect”
$directruleInstance = $directruleClass.CreateInstance()$directruleInstance.ResourceClassName = “SMS_R_System”

With that done, we can use the Powershell Get-WmiObject commandlet to find the ‘Test’ computer. As you may have noticed, this is the first time we are going to be using a commandlet in our PowerShell script. Anyway, we are going to assume that we only have one instance returned (meaning that there is only one computer object (System resource instance) in the database).  In reality there may be multiple objects with similar names, so you will want to either filter them more or use a foreach loop (foreach-object commandlet) to walk through the collection of returned computer objects.

$computer = Get-WmiObject –class “SMS_R_System” – namespace “root\SMS\Site_LAB” –Filter “NetbiosName = ‘Test’”

All we need to do is link the ResourceID property in the found computer object with the rule object’s ResourceID property, as such:

$directruleInstance.ResourceID = $computer.ResourceId

Then, we call the AddMembershipRule method from our new collection, and tie it to the new Direct Memebership rule instance we created just now.

$collection.AddMembershipRule($directruleInstance)

Finally, we call the RequestRefresh method to ask Collection Evaluator in the site to update the collection membership for our new collection and that it!

$collection.RequestRefresh()

Assuming I haven’t bored you to death with my comments so far, this is what you should have in the end:

$collClass = [WMIClass] “root\SMS\Site_LAB:SMS_Collection”
$collInstance = $collClass.CreateInstance()
$collInstance.Name = “FooCollection1”
$collInstance.OwnedByThisSite = $true
$collPath = $collInstance.Put()
$collection = [WMI] $collPath.Path
$subcollClass = [WMIClass] “root\SMS\Site_LAB:SMS_CollectToSubCollect”
$subcollInstance = $subcollClass.CreateInstance()
$subcollInstance.parentCollectionID = “COLLROOT”
$subcollInstance.subCollectionID = $collection.CollectionID
$subcollection = $subcollInstance.Put()
$directruleClass = [WMIClass] “root\SMS\Site_LAB:SMS_CollectionRuleDirect”
$directruleInstance = $directruleClass.CreateInstance()
$directruleInstance.ResourceClassName = “SMS_R_System”
$computer = Get-WmiObject –class “SMS_R_System” – namespace “root\SMS\Site_LAB” –Filter “NetbiosName = ‘Test’”
$directruleInstance.ResourceID = $computer.ResourceId
$collection.AddMembershipRule($directruleInstance)
$collection.RequestRefresh()

Hopefully, the above sample will be useful in letting you understand how you can use PowerShell with ConfigMgr’s WMI Provider.  If this has been helpful to you, please let me know by commenting below.