none
R2 - Cannot change Primary Management Server RRS feed

  • Question

  • Just upgraded to R2 a few days ago, and only just realised that some servers that needed the agent un-installed and re-installed, are not able to have their Primary management Server changed. ( from RMS to 2ndary MS). (The install of the R2 agent went fine)
    Has anyone else come across this issue in R2?
    Thx,
    John Bradshaw
    Monday, July 27, 2009 2:18 AM

Answers

  • In R2 we block the ability to remotely manage manually installed agents.  This was decided due to issues customers ran into while trying to manage AD Integrated agents and update agents behind firewalls. 
    Rob Kuehfus | System Center Operations Manager | Setup and Deployment Program Manager
    Monday, July 27, 2009 11:34 PM
    Moderator

All replies

  • Hi John

    Are these manually installed agents?

    Cheers

    Graham
    View OpsMgr tips and tricks at http://systemcentersolutions.wordpress.com/
    Monday, July 27, 2009 8:03 AM
    Moderator
  • If is manuall installed agents, like agents on a DMZ, you could change it with a PS command, take a look at http://contoso.se/blog/?p=831
    Anders Bengtsson | Microsoft MVP - Operations Manager | http://www.contoso.se
    Monday, July 27, 2009 9:52 AM
    Moderator
  • Hi Graham,
    Yes, Manually installed, but I've never had an issue with them b4 under SP1.
    Thx,
    John Bradshaw
    Monday, July 27, 2009 9:34 PM
  • Hi John

    I've noticed this under R2 as well - as Anders has mentioned, you can change it via powershell but I was just interested to find out if you were seeing the same as me.

    Have fun

    Graham

    View OpsMgr tips and tricks at http://systemcentersolutions.wordpress.com/
    Monday, July 27, 2009 10:18 PM
    Moderator
  • In R2 we block the ability to remotely manage manually installed agents.  This was decided due to issues customers ran into while trying to manage AD Integrated agents and update agents behind firewalls. 
    Rob Kuehfus | System Center Operations Manager | Setup and Deployment Program Manager
    Monday, July 27, 2009 11:34 PM
    Moderator
  • Well that explains it.....Bit sad if I chose the RMS to act as the MS....Need to think what I'm doing now, as there is no back door :)
    JB
    Tuesday, July 28, 2009 1:44 AM
  • In R2 we block the ability to remotely manage manually installed agents.  This was decided due to issues customers ran into while trying to manage AD Integrated agents and update agents behind firewalls. 
    Rob Kuehfus | System Center Operations Manager | Setup and Deployment Program Manager

    Hi Rob

    Does this mean that we can't remotely manage by Powershell as well? Or is this just a GUI constraint?

    Cheers

    Graham
    View OpsMgr tips and tricks at http://systemcentersolutions.wordpress.com/
    Tuesday, July 28, 2009 9:45 AM
    Moderator
  • Not sure I understand you question, but it is possible to remotely run the PS commands I posted, and configure agents and gateway servers. When I did the tests I ran both the ops mgr console and ops mgr command shell from a workstation.
    Anders Bengtsson | Microsoft MVP - Operations Manager | http://www.contoso.se
    Tuesday, July 28, 2009 10:24 AM
    Moderator
  • Hi Anders

    Rob has stated that on R2, MSFT has blocked the ability to remotely manage manually installed agents.

    I am asking for clarification on whether this "remote managed" is blocked via the GUI only (you certainly can't change Management servers for manually installed agents in the GUI any more). Or is remote management of manually installed agents blocked even if you use powershell. It would seem pointless blocking remote management from the console if it is allowed via Powershell, especially as this is MSFT trying to stop administrators from this activity due to other issues it can cause. 

    I'm not disputing the fact that it is possible to remotely run the PS commands ... but do they actually do anything? Do they actually change the primary management server that the agent will use? And should they even be used? From what Rob is saying, remotely managing manually installed agents is not good practice - especially when AD Integration is used.

    Hope that makes sense

    Cheers

    Graham


    View OpsMgr tips and tricks at http://systemcentersolutions.wordpress.com/
    Tuesday, July 28, 2009 10:33 AM
    Moderator
  • The ps commands I was thinking of does change the management servers for a agent. there are other examples of things you can do with PS but not with the console, like export a sealed MP
    Anders Bengtsson | Microsoft MVP - Operations Manager | http://www.contoso.se
    Tuesday, July 28, 2009 3:13 PM
    Moderator

  • Hi Anders

    I think you're missing the main point I am seeking clarification on - apologies for my poor explanation. I'll try again ;-)

    Rob has stated that on R2, MSFT has blocked the ability to remotely manage manually installed agents .

    This is deliberate and the reason given by Rob for blocking the remote management of manually installed agents is that it can cause problems with AD Integration.

    So ... the clarification I was asking for from Rob was:

    - if remotely managing manually installed agents causes potential problems with AD Integration then should the powershell scripts be used at all?

    - if AD Integration isn't being used, is it ok to remotely manage the agents?

    Cheers

    Graham

    View OpsMgr tips and tricks at http://systemcentersolutions.wordpress.com/
    Tuesday, July 28, 2009 3:36 PM
    Moderator
  • Graham, did you receive any clarification you were asking for from Rob?

    Just in case someone ran into the same trouble it should be noted here that Set-ManagementServer still works perfectly as expected on R2 (Graham 090728 1033: the commands actually do what we expect).

    Hopefully this functionality will never be switched off or get unsupported; we deploy and maintain agent packages using our (non-SCOM) deployment infrastructure (no AD based assignment). While we are not interested in the GUI (where an unsupported workaround would be to modify MT_HealthService / IsManuallyInstalled = False), we are heavily dependent on the ability to centrally reconfigure primary and failover management servers as needed; Set-ManagementServer is fine w.r.t. to the method.

    So I'd really like to see answers to Grahams question:
    - if AD Integration isn't being used, is it ok to remotely manage the agents using Set-ManagementServer?

    Regards
    Josef

    Thursday, October 15, 2009 7:43 AM
  • That's good to know.
    Is it possible to run a remote repair on a manually installed agent to be able to remotely manage it later on, or do we have to uninstall the agent and push it from the MS?
    Thursday, October 15, 2009 7:50 AM
  • Some further considerations:

    The issue originally came up because the GUI blocks "Change Primary Management Server" for manually installed agents on R2 (note that wording "manually" is misleading somehow). 
    However, actually the following context verbs on "Agent Managed" are blocked:
    a) "Change Primary Management Server"
    b) "Repair ..."
    c) "Uninstall..."

    As Rob stated, "This was decided due to issues customers ran into while trying to manage AD Integrated agents and update agents behind firewalls."
    This is clear to everyone for b) and c) since repair and uninstall are done by remoteley triggering msiexec on the agent using RPC (this explains the firewall problems) and because an msiexec repair might damage a configured AD integration.
    (BTW: centrally triggering Windows Installer on agents using this method might be nice for lab environments but is really inadequate and impossible for enterprise scenarios with dozens of firewalls.)

    While it is tempting to apply this argument for a) as well - because changing at least the primary MS is also possible using an appropriately parameterized msiexec - , a) seems to be completely different:
    I tested a) using the GUI as well as a Set-ManagementServer based ps1 and found that it worked - thank god - without msiexec being ever involved and without ports other than 5723 being involved (netmon). After some time the well known events 21024 and 21025 show up and communication continues with the new primary management server.
    (Note that the tests were done without AD integration)

    Maybe I'm missing something, but could it be that - in an attempt to prevent firewall and AD integration related problems - :
    - the GUI not only blocks b) and c) but inadvertently also a) ?
    - a) should only be blocked for agent with AD integration (if at all) ?

    To summarize, I would like to add the following to Graham's (still unanswered) questions to Rob:

    - Why did you block the "Change Primary Management Server" verb for agents with IsManuallyInstalled=True and ActiveDirectoryManaged=False ?

    Regards
    Josef

    Thursday, October 15, 2009 11:07 AM
  • Actually it is not the GUI that blocks the "Change Primary Management Server" option. Our manually installed agents, which were installed when running SP1, are still manageable with this feature after the upgrade to R2.

    Only new manually installed agents are "blocked" from the GUI.
    When approving a manually installed agent, the required database value for this interface function is not set. Setting this value manually will again give you the "Change Primary Management Server" option for agents installed with a running R2 configuration.
    Thursday, November 5, 2009 7:20 AM