Quick download: https://github.com/thekevinholman/MultiHomeSCOMAgents
I have written solutions that include tasks to add and remove management group assignments to SCOM agents before:
https://kevinholman.com/2017/05/09/scom-management-mp-making-a-scom-admins-life-a-little-easier/
But, what if you are doing a side by side SCOM migration to a new management group, and you have thousands of agents to move? There are a lot of challenges with that:
1. Moving them manually with a task would be very time consuming.
2. Agents that are down or in maintenance mode are not available to multi-home
3. If you move all the agents at once, you might overwhelm the destination management group, or your local virtualization hosts with the simultaneous activity.
I have written a Management Pack called “SCOM.MultiHome” that will manage these issues more gracefully.
It contains one (disabled) rule, which will multihome your agents to your intended Management Group and Management Server. This is also override-able so you can specify different management servers initially if you wish:
This rule is special – in how it runs. It is configured to check once per day (86400 seconds) to see if it needs to multi-home the agent. If it is already multi-homed, it will do nothing. If it is not multi-homed to the desired management group, it will add the new management group and management server.
But what is most special, is the timing. Once enabled, it has a special scheduler datasource parameter using SpreadInitializationOverInterval. This is very powerful:
<DataSource ID="Scheduler" TypeID="System!System.Scheduler"> <Scheduler> <SimpleReccuringSchedule> <Interval Unit="Seconds">86400</Interval> <SpreadInitializationOverInterval Unit="Seconds">86400</SpreadInitializationOverInterval> </SimpleReccuringSchedule> <ExcludeDates /> </Scheduler> </DataSource>
What this will do, is run once per day, but the workflow will not initialize immediately. It will initialize randomly within the time window provided. In the example above – this is 86400 seconds, or 24 hours. This means if I enable the above rule for all agents, they will not run it immediately, but randomly pick a time between NOW and 24 hours from now to run the multi-home script. This keeps us from overwhelming the new environment with hundreds or thousands of agents all at once. You can even make this window bigger or smaller if you desire by editing the XML here.
It is literally THAT simple.
How to use the MP
IF you do not have any Gateways in your environments, then you can go ahead and import the MP and simply override the rule “SCOM Multihome Agent to Additional Management Group Rule” for ALL agents:
HOWEVER – If you have gateways:
If you have gateway servers, you need special handling for these FIRST before you enable the rule for the rest of the agents. Therefore, you need to take some steps first.
BEFORE YOU IMPORT the MP, open the XML with Notepad++ and edit a few things.
FIRST, you need to change the DisplayName of the Group to match your NetBIOS name for YOUR gateway. This MP supports up to 10 gateways. If you have more than that – you will have to some advanced XML work.
Find the “LanguagePack” section of the XML, and change the Gateway NetBIOS name for each group and discovery. My Gateway is named “GW1.opsmgr.net” so I put in “GW1” here. You need to change this for your gateways. If your first Gateway is “A123OMGW1.contoso.com” then you would change GW1 (highlighted below) to A123OMGW1 (NetBIOS name only, NOT FQDN). Easy peasy. Repeat this for up to 10 gateways.
Next, you need to ENABLE the discoveries for your Gateways.
Import the MP, then browse to Authoring > Object Discoveries in the console. Search for “multihome”:
You must ENABLE any Gateway Group Discoveries that you modified in the XML so these will run. You can just open the properties of each discovery and check the box to enable them.
Now your groups should populate. Be patient, this process can take up to 15 minutes in large environments.
Browse the console at Authoring > Groups. Search for “Gateway”.
On each Gateway Group, choose “View Group Members”. The number of agents should match the agents count shown under Administration > Agent Managed for that Gateway.
Check EACH Gateway Group. Once you have confirmed these are all correct, you can review the group “All Agents NOT Assigned to Gateways Group”. This group should contain all the agents that are assigned to management servers.
If the groups are all correct, you can start using these groups to override the “SCOM MultiHome Agent to Additional Management Group Rule”. Override this rule “for a Group” and choose each group in the MP, and input the new Gateway or Management Server Name.
If you have more than 3000 agents, you should use my Load Balancer MP to keep your agents assigned to management servers load balanced: Automating Agent Load Balancing for Management Servers and Gateways – Kevin Holman’s Blog
Wrap up:
Using this MP, we resolve the biggest issues with side by side migrations:
-
No manual multi-homing is required.
-
Gateways can be assigned correctly and easily
-
Agents that are down or in maintenance mode will multi-home when they come back up gracefully.
Quick download: https://github.com/thekevinholman/MultiHomeSCOMAgents
Can I apply this to only select group of Agents? Where will this MP be installed – in the management group where agents are currently running or the Management group where the agents will be migrated over?
Will there be an impact on the monitoring behavior if the agent version of my new management group is different from the current management group that is live?
Yes, via a group. Install this MP in the “old” management group. As far as different agent versions, you should review the supported coexistence statements in the product documentation.
Hello Kevin, sorry for guffy question but how I can do it via group? should I change the xml before import? Thank you.
Is this also for Agents with Version 8.0.13053.0? I can’t Add Agents to my new envoirment
Hi Kevin,
I have installed the MP on SCOM 2016, though i dont see the agents getting populated in the group automatically. Do we have to enable any other settings apart from enabling the rule. I have changed the agent count to 100, as for now we are monitoring 600 Servers overall.
Regards,
Vipin
Those groups only populate once a day based on a sync time. Wait long enough, and look on your management servers for the events they log to see whats going on.
Thank you!
Thanks a lot, It worked 😀 :D..
Hi Kevin, We just started using the MP on a SCOM 2019 install. I believe that I found an issue with the way that the MStoASSIGN$ parameter gets passed to the SCOM.MultiHome.AddMG.Rule.WA.ps1 PowerShell script. For some reason, a space is getting added to the end of the string which caused an exception when the AddManagementGroup method was called? I updated the PowerShell code and added $MStoASSIGN = $MStoASSIGN.Trim() and the issue seems to be fixed.
Exception calling “AddManagementGroup” with “3” argument(s): “The parameter is incorrect. (Exception from HRESULT: 0x80070057 (E_INVALIDARG))”
Hi Kevin,
How to upgrade SCOM Agents after Multihome as version will remain old after it also
Regards,
Rohit
Kevin,
I’ve said it before and I’ll say it again. You are absolutely amazing. Thank you very much for all your fantastic contributions to SCOM community. I know I’ve appreciated a lot.
Cheers
G
Thanks!
In our current environment we set global management server settings to – “review new manual agent installations in pending management”. Will this management pack just add the SCOM agents to the new management group without being approved because they already were previously approved in the old management group?
No, they will show up in Pending as a “manually installed” agent in the new MG.
Hey Kevin,
What is supposed to be the target of the override? Is it a group or the agent class? I did the agent class in dev it work but when I try the group it did not work in prod?
For small environments – just override the rule for the Agent class. This will start multihoming ALL agents.
For big environments – this is where the override should be scoped to a Group. Check the group memberships to ensure they first have populated with agents.
I can see how this will make any managed agent multihome. So how is the cleanup handled to make the switch in a side by side like you suggest?
Once they are in the new environment, you could script the removal, or use my SCOM Management MP: https://kevinholman.com/2017/05/09/scom-management-mp-making-a-scom-admins-life-a-little-easier/
Kevin, this MP does not show Linux agents in any views. Can this be done?
The add/remove SCOM group does not seem to show and thus apply on Linux agents. That’d mean that linux agents cannot (yet) be migrated in a side by side situation?
Linux multihoming is far more complex. This is only for Windows agents.
Hi Kevin,
Seems this link is broken. Would you be able to share the script again.
The link at the top works fine. GitHub
The multihome script works like charm! 🙂
But how about removal? The link seems broken.
Thanks Kevin
This one? https://kevinholman.com/2017/05/09/scom-management-mp-making-a-scom-admins-life-a-little-easier/
Kevin,
What is your experience with multi-homing Linux agents? I am looking to multi-home our old 1807 setup to a 2019 setup but I’m a little bit afraid this may cause issues as the agent for SCOM 2019 is newer.
Are these compatible with each other?
Hi Kevin,
Do I need to upgrade my 2012r2 agents from v7 to v10 prior to dual homing?
Will the 2012 environment still communicate with v10 agent?
Will the v7 Agent communicate with SCOM 2019 environment?
Thanks
A 2012R2 agent will communicate with a SCOM 2019 management group.
A 2019 agent will communicate with a SCOM 2012R2 management group.
One caveat – this is not supported by the product group. They support the following coexistence: https://docs.microsoft.com/en-us/system-center/scom/system-requirements?view=sc-om-2019#supported-coexistence
However, it does work and most people do this.
If you want to be careful and FULLY supported… you can upgrade all your SCOM 2012R2 agents to SCOM 2016. SCOM 2016 agents are supported communicating with a 2012R2 management group AND a SCOM 2019 Management Group.
Hi Kevin,
I downloaded and installed your MultiHome MP into our SCOM 2012 R2. When i scope the Management Pack Objects, i only find the the targets for the “SCOM MultiHome GroupX SQLQueryBased” from the Management Pack SCOM Multihome. For some reason, the mentioned Rule is not present.
regards,
Georg
The rule targets the “Agent” class.
Thanks Kevin!
Thank you so much for the knowledge and skills you share. They’re invaluable. We plan to use this tool to migrate our 8,000 systems from SCOM 2012 to SCOM 2019. I can use the SpreadInitializationOverInterval and EndNumber fields to increase the number of machines per group to 1,000 and stretch the run time to 8 hours. But is there any way to control the machines processed in a more granular way? About 200 of our systems are Windows 2008 and won’t be migrated. Another significant bunch are mission critical and must be moved carefully/manually. Finally, Management would like to see a successful pilot using well less than 1,000 servers!! Any ideas on how to select specific machines from these 8 groups? Thanks!
There are a few things you can do.
You can put in the multi-homing script, to check the OS version, and do nothing if it is 2008 OS.
You can also create your own custom groups…. you don’t need to use mine…. or use group exclusions to exclude specific members from the groups. This way you can verify your groups are good to go, before taking action. You can edit the group membership count to any number you want, for a pilot, or just create a custom group. The groups are only used for simple overrides.
I’m assuming this won’t work for SCOM 2012 SP1 to 2019, all references to 2012 appear to be R2 only.
It should work in any version of SCOM I believe. You can change the reference versions.
Hi Kevin, We are having SCOM 2019 Agents on our machines and we would like to multihome the 2019 agent back to SCOM 2012 R2 Management Server. is it compatible ?
If not can the SCOM 2019 agent at least report to SCOM 1801 verion ?
It works fine – it just isn’t supported because Microsoft didn’t test that scenario.
Hello Kevin,
Could you please send me or advise on where to Solaris agent software to deploy agents on Solaris servers?
Hello Kevin,
Could you please send me or advise on where to get Solaris agent software to deploy agents on Solaris servers?
Hi Kevin. The link https://gallery.technet.microsoft.com/SCOM-Agent-Management-b96680d5 seems to be broken.
“No results
Sorry, we couldn’t find anything that fit your search.”
Do you have a link for this?
I managed to find it on your github. Thanks Kevin.
https://github.com/thekevinholman/MultiHomeSCOMAgents
Hi Kevin,
After we multihome, what is the best way to upgrade the scom agent on clients from 2012 to 2019? Is there any script that we can upgrade remotely in bulk instead of manually installing 2019 msi?
1. SCCM
2. Develop a MP with the agent included, and a tested upgrade script…. https://kevinholman.com/2019/11/18/advanced-mp-authoring-mpu-nov-2019/
Hi Kevin,
We use multihomed agents for the agent servers, but is there a way a gateway servers to be multihomed? If yes can you please share how?
Gateway servers cannot be multihomed. They can service a single management group only.
Hi Kevin. I am a little bit confused. There are currently 3 MPs present on your link and all are SCOM.Multihome when imported in SCOM. Am I correct to assume that I will only use one of these MPs? Let say if I want to use the groupings in case I have large number of agents, I will install the version 1.0.0.2 this MP basically has the groupings. If I only have a small environment, I can use either the version 1.0.0.7 or the other one. I have used the version 1.0.0.7 but I don’t see any agents transferring to the new MG. I override SCOM MultiHome Agent to Additional Management Group Rule parameters: Enabled, MGtoAdd and MGtoAssign. This is targeting Class Agent. Please let me know if I am getting this correct. Thanks.
SCOM.MultiHome.xml – basic simple MP with a rule to multihome agents.
SCOM.Advanced.MultiHome.xml – advanced MP with multiple groups to control multi-home activities for huge environments.
SCOM.MultiHome.GW.xml – advanced MP which required XML editing – to customize for a customer with up to 5 gateways. This required advance authoring experience if you have more than 5 gateways.
Thanks Kevin. I figure it out. I forgot to change the security settings to enable review new manual agent installation in pending management. My bad. Currently setting up my test environment of SCOM 2019. Thanks for your help.
Kevin, I have a prod 2016 SCOM env and created a side-by-side 2019.
2016 has 4 mgmt servers (let’s call them 2016-01, 02, 03 and 04) for a total of 4500 VMs. 2019 will only have 2 mgmt servers (let’s call it 2019-01 and 02).
2016-01 has 2500 VMs and can go to 2019-01
2016-02 has 600 – goes to 2019-02
2016-03 has 900 – goes to 2019-02
2016-04 has 500 – goes to 2019-02
If I understand your Multihome MP correctly, I would install the MP to 2016-01, set the destination mgmt server to 2019-01 and run the advanced group and that should only multihome the VMs in 2016-01 to 2019-01?
Then I would repeat the MP on 2016-02,03 and 04 and change the mgmt server destination to 2019-02?
I just want to make sure that when I perform the MP on 2016-01, it does ONLY the VMs residing within that mgmt server and not all 4.
Hi Kevin, I would like to know how about Audit Collection after a successful multihoming? Since we are doing side-by-side migration, I will be setting up again ACS in the new server. Will the domain controllers be forwarding on both collectors, in our case old and new SCOM management servers? I haven’t done anything yet as I don’t know the effect yet. Hope to hear your thoughts as to how to move old forwarding to the new server and what is the best way to do it. Thanks.
ACS does not support multi-home. You must switch your forwarders to point to the new collector.
Thank you very much. 🙂
This MP as already saved me a ton of time. However my environment has 3 domains and it of course only worked on the primary domain that my SCOM servers sit in. The other two domains point to GW servers for their respective domains. I have groups created in SCOM 2012 R2 for the respective domains, however when go to assign the MP to a group for override, those groups don’t show up in the list.
Hi Kevin,
I’m struggling with this one for some reason (MP version 1.0.1.0).
I added my gateway NetBIOS names as instructed in place of the GW1…10 place holders in the respective DisplayString’s Name entries and all show correctly in SCOM – but only the first GW group populated.
The first time I tried this pack, the event log only showed the first discovery running.
When I went to activate the discovery rules, I noticed that the GW1 discovery was already enabled and the GW2 rule was also targeting GW1.
After correcting that in the XML, reimporting and enabling the discoveries for my other gateways (5), I still could only see the first gateway populate.
.
I tried again by importing a modified version of the MP with a new namespace so I could import it in parallel.
This time I started to see more discoveries run but not all the ones I enabled.
Despite other discoveries now running, I still could only see the first group populate even though I could see the event log entries indicating the agents were being detected against the other gateways.
I also saw a couple of relationship-based errors pop up but only on 2 of the five discoveries enabled. This seemed to resolve itself possibly due to the relationship association running before the respective group was fully discovered. (?)
Again, I tried with a different gateway assigned as GW1 and this populated successfully with the different agents expected. But the other GW Groups failed to populate including the one I had assigned to GW1 originally. My guess is that there seems to be some sort of relationship conflict.
I have 3 management groups (2016) that I’m combining into one new SCOM 2022 management group where this solution would be of great help if I can get it working.
Ken – you were spot on. I fixed the bugs in 1.0.1.2
Thanks Kevin!
In the interim, I created a new version that automatically discovers the gateways in your Management Group and creates the nominal number of groups required for overrides (no limit) negating the need to customize the XML before importing. I’m sharing it on my GitHub page in an unsealed format initially until I get around to uploading the full Visual Studio Project: https://github.com/KenHamilton/SCOM-Multi-Homing. I plan to add some sort of Dashboard/s for tracking progress and maybe utilizing your SCOM Management MP so we can see all Management Groups configured on the target Agents. Obviously and feedback or contributions are welcome!
OMG that sounds amazing. I’m checking that out.
Ok that thing is freaking bizarre.
You created a group with a class property. I have never seen that.
Then – you created a group that is non-singleton. Also never seen. I mean, the whole definition of a group has always been Singleton by nature.
That said, I don’t know why. A group is just an instance of class. And a class can contain other instances.
But then you have NO display strings for your group class. What do they look like when you try to use them via overrides in the console?
New repository created with Visual Studio Solution:
https://github.com/KenHamilton/SCOM.Multihoming.ManagementPack.git
Added support for automatically creating groups for Management Servers. This is good for large
environments so you can retain agent distribution.
The dynamic group creation technique I got from this old post: https://janscman.wordpress.com/2012/11/27/dynamically-creating-groups/
The Group’s Display String is populated as part of the discovery script. They look like:
“Gateway Agent Group “
the display name got truncated… it should be:
Gateway Agent Group “Gateway FQDN”