none
Installing SCOM roles (not agents) using SCCM RRS feed

  • Question

  • Is this possible? We've got working command lines for most roles (if anyone knows how to install ACS at the command line - my guess is standard .msi commands will work, but we haven't tried that one yet), but when we try to deploy using SCCM the install just spins forever. Initially we though that perhaps this was a user profile issue, but it does not appear to be. Although I will caveat that with no log files are written to the temp profile that gets created during the install. Has anyone successfully deployed via SCCM? We would prefer to do this over DSC (aka Puppet DSL), but we seem to be stuck.
    Monday, June 24, 2019 5:00 PM

Answers

  • Just to close out this post, I was able to overcome this by using a command line rather than PowerShell to do this. The behavior is kind of weird, but we ended up putting everything in a task sequence, and then adding a set of steps to do our pre-build "stuff" and then run a command line to do the install. So rather than one step, we needed more. But we do have it working as expected/intended at this point. Thanks for the input!
    • Marked as answer by HS Brown Friday, June 28, 2019 10:58 PM
    Friday, June 28, 2019 10:58 PM

All replies

  • Hi,

    Yes this should be possible to achieve this with SCCM, as you already have the command line options out there.

    I haven't personally done it with SCCM though, but I have deployed a fully functioning SCOM environment with Orchestrator, I have managed this with both Batch and PowerShell methods.

    So at least by using the above two methods should work fine with SCCM.

    Unfortunately you cannot install the ACS role from the command line, you might have noticed that there isn't documented anything for the command line for the ACS either.

    Best regards,
    Leon


    Blog: https://thesystemcenterblog.com LinkedIn:

    Monday, June 24, 2019 7:14 PM
  • Hi

    After doing a lot of research, I didn't find the command to install ACS role, either. 

    Best regards.

    Crystal


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Tuesday, June 25, 2019 3:11 AM
  • The plot thickens...

    We've been able to get this to start from SCCM, but the install fails every time from SCCM:

    [15:05:17]: Always: :ValidateActionAccount: account is <DOMAIN>\<SCOMADMINACCOUNT>
    [15:05:17]: Error: :Error:Failed to log in with account <DOMAIN>\<SCOMADMINACCOUNT>
    [15:05:17]: Always: :ValidateActionAccount: account after ValidateEssentialsAdministratorAccount is <DOMAIN>\<SCOMADMINACCOUNT>
    [15:05:17]: Error: :User Account is not valid.  Please use pass a valid Domain, User, and Password
    [15:05:17]: Error: :Error:Action Account information could not be validated correctly.
    [15:05:17]: Error: :Could not validate the management action account information.
    [15:05:17]: Always: :End: Rationalize command line arguments (first run).
    [15:05:17]: Error: :RationalizeComponents blocked because: Could not validate the management action account information.
    [15:05:17]: Always: :End: Rationalize components.
    [15:05:17]: Error: :We could not rationalize the component choices.  We must fail.

    Any ideas or assistance would be greatly appreciated.

    Thursday, June 27, 2019 10:28 PM
  • How does the commands look like?

    I had similar errors with the accounts when I didn’t use a one-liner command (i.e. was using separate lines)


    Blog: https://thesystemcenterblog.com LinkedIn:

    Friday, June 28, 2019 5:14 AM
  • The command line is invoked via PowerShell. The script works when executed in PoSh, it fails with the above errors when invoked via SCCM. We can see the account appears to work, but we are using a service account. We may try a real user account today, to see if that resolves it. If not, I'll be back...
    Friday, June 28, 2019 3:35 PM
  • Executing as a user account made no difference. I'm completely stumped.
    Friday, June 28, 2019 4:16 PM
  • Just to close out this post, I was able to overcome this by using a command line rather than PowerShell to do this. The behavior is kind of weird, but we ended up putting everything in a task sequence, and then adding a set of steps to do our pre-build "stuff" and then run a command line to do the install. So rather than one step, we needed more. But we do have it working as expected/intended at this point. Thanks for the input!
    • Marked as answer by HS Brown Friday, June 28, 2019 10:58 PM
    Friday, June 28, 2019 10:58 PM
  • Glad to hear you solved it! Yeah there is some difference between PowerShell and the Command Prompt, I don't know all of them but this is one reason I still use the good old Command Prompt for many things :)

    Blog: https://thesystemcenterblog.com LinkedIn:

    Saturday, June 29, 2019 7:07 AM
  • I wanted to add a bit more to this, for anyone who might want to do this. We discovered this when attempting to do a bare-metal deployment.

    First, you cannot install SCOM (it seems) as SYSTEM. It expected to write the install logs to a User Profile directory, C:\Users\<username>\AppData\Local\SCOM, which it appears to be unable to do as SYSTEM. Further, if you use a user account with admin rights on the box, the installation will fail for the same reason - not user profile.

    So, we essentially copied the user profile entry from the registry under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\<account SID>, and cloned all the directories in C:\Users\<username> from another server, and wrote a PowerShell script to add it to the registry, and drop the folder structure into the appropriate place.

    This worked fine when executed as a user, but when executed as SYSTEM through SCCM (because to run it as a user would require elevation), it appended a ".bak" to the profile in the registry, and when viewed with User Profile manager in Advanced System Settings, the profile showed as "Backup", and STILL didn't work.

    The final piece was to add to the script, to rename the profile after import to remove the ".bak" that was added to the profile when imported by SYSTEM.

    Once that task was added to the sequence, we were able to install on a bare-metal server that had no user profile created for the installer account.

    It might be worth revisiting the installer...

    Tuesday, July 2, 2019 8:55 PM