none
Powershell Write Action module using OM12 cmdlet's RRS feed

  • Question

  • I'm trying to knock off the rust as I haven't used powershell in a while, but I'm pretty sure it was possible to issue OpsMgr cmdlet's from within a powershell rule in the past.

    I'm using the Microsoft.Windows.PowershellWriteAction module, targeting the RMSE (which runs under MSAA by default), and it seems the OperationsModule isn't able to connect to the management group.

    $oAPI = New-Object -comObject "MOM.ScriptAPI"
    $oAPI.LogScriptEvent("MyScript.ps1",555,0,"MyScript started.")

    try {
        Import-Module OperationsManager
        New-SCOMManagementGroupConnection myRMSE
        Get-SCOMManagementGroupConnection -ManagementGroupName myManagementGroup | Set-SCOMManagementGroupConnection
        $oAPI.LogScriptEvent("MyScript.ps1",555,0,"Connected to management group.")
    }
    catch {
    $oAPI.LogScriptEvent("MyScript.ps1",555,0,"Could not connect to management group.")
    }

    I run the script locally, and it connects to MG fine. I put this into a rule, and it's not connecting fine. Any thoughts?


    Jonathan Almquist | SCOMskills, LLC (http://scomskills.com)

    Tuesday, February 5, 2013 10:56 PM
    Moderator

Answers

  • Try importing it using the psm file:
    Import-Module "C:\Program Files\System Center 2012\Operations Manager\Powershell\OperationsManager\OperationsManager.psm1"

    Thursday, February 7, 2013 4:56 PM

All replies

  • Deleted
    Wednesday, February 6, 2013 9:51 AM
  • Hi David,

    This is running on RMSE and the default action account is a member of the SCOM Admins user role.

    I'll take your suggestion to add more details around the try/catch - good tip.

    Thanks!


    Jonathan Almquist | SCOMskills, LLC (http://scomskills.com)

    Wednesday, February 6, 2013 1:32 PM
    Moderator
  • Got to the office and added exception info to the event, and getting this:

    The term 'New-SCOMManagementGroupConnection' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again. The specified module 'OperationsManager' was not loaded because no valid module file was found in any module directory.

    Still digging - will update the thread once I figure this out. any other tips would be helpful.


    Jonathan Almquist | SCOMskills, LLC (http://scomskills.com)

    Wednesday, February 6, 2013 5:02 PM
    Moderator
  • The specified module 'OperationsManager' was not loaded because no valid module file was found in any module directory.


    Looks like the OperationsManager module isn't correctly registered as it's failing to be recognised.  Since this is added by modifying the PSModulePath environment variable, it might be the case that the action account either doesn't have access to that variable (or the resolved path) or has a conflicting user variable setting setup.

    Can you open a PS session as the action account user and check your $env:psmodulepath includes C:\Program Files\System Center 2012\Operations Manager\Powershell\ ?

    Sample below:

    C:\Users\mlong\Documents\WindowsPowerShell\Modules;C:\Windows\system32\WindowsPowerShell\v1.0\Modules\;C:\Program Files\Common Files;C:\Program Files\System Center 2012\Operations Manager\Powershell\

    Hope that helps!

    Wednesday, February 6, 2013 6:07 PM
  • That doesn't seem to be the issue. Looks like your example, with the exception that C:\Program Files\System Center 2012\Operations Manager\Powershell\ is in there twice...

    A little perplexed at the moment. I know in SCOM 2007 we had to do a bunch of setup to use the SCOM cmdlet's, but is this still valid? We should be able to simply import-module?


    Jonathan Almquist | SCOMskills, LLC (http://scomskills.com)

    Wednesday, February 6, 2013 8:40 PM
    Moderator
  • Yeah you should be able to just add the module (the Operations Manager module is x86/x64 compatible, so there's non of the nonsense you have with some of the other modules/snappins in the suite).  It is a script implemented module however, so you will get errors if your Execution policy is too restrictive (Remotesigned will be fine).  You aren't getting the appropriate exception for that kind of behaviour however so i doubt that's an issue...

    Out of interest, when running as the action account, what output do you get from Get-Module -ListAvailable, and is the OperationsManager module listed?

    Wednesday, February 6, 2013 10:51 PM
  • Deleted
    Thursday, February 7, 2013 12:18 PM
  • I have a rule very similar to yours and is working fine. Can you execute the powershell script under MSAA account?
    Thursday, February 7, 2013 1:38 PM
  • Mathew is on the right track. OperationsManager is not in the list of modules. All I get is: ADRMS, AppLocker, BestPractices, BitsTransfer, PSDiagnostics, ServerManager, TroubleshootingPack

    The workflow is being executed by the management server action account, which is a member of the SCOM Admins user role - verified that by inserting an event with whoami. The interesting thing is, when I log into the local MS with the MSAA, the script runs fine and OperationsManager module is in the list...

    This is the script I'm running in the MP.

    $oAPI = New-Object -comObject "MOM.ScriptAPI"
    $oAPI.LogScriptEvent("MyScript.ps1",555,0,"Script started.")

    try {
        Import-Module OperationsManager
        $a = Get-Module -ListAvailable
        $b = whoami
        $oAPI.LogScriptEvent("MyScript.ps1",555,0,$a -join ", ")
        $oAPI.LogScriptEvent("MyScript.ps1",555,0,$b)
    }
    catch [system.exception] {
    $oAPI.LogScriptEvent("MyScript.ps1",555,0,$error)
    }


    Jonathan Almquist | SCOMskills, LLC (http://scomskills.com)

    Thursday, February 7, 2013 4:25 PM
    Moderator
  • Here is the xml if it helps
    <ManagementPack ContentReadable="true" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
      <Manifest>
        <Identity>
          <ID>MyMP.OperationalWorkflows</ID>
          <Version>1.0.0.21</Version>
        </Identity>
        <Name>My MP - Operational Workflows</Name>
        <References>
          <Reference Alias="SC">
            <ID>Microsoft.SystemCenter.Library</ID>
            <Version>6.1.7221.0</Version>
            <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
          </Reference>
          <Reference Alias="Windows">
            <ID>Microsoft.Windows.Library</ID>
            <Version>6.1.7221.0</Version>
            <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
          </Reference>
          <Reference Alias="System">
            <ID>System.Library</ID>
            <Version>6.1.7221.0</Version>
            <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
          </Reference>
        </References>
      </Manifest>
      <TypeDefinitions>
        <SecureReferences>
          <SecureReference ID="MyMP.OperationalWorkflows.MyWorkflowProfile" Accessibility="Internal" Context="System!System.Entity" />
        </SecureReferences>
        <ModuleTypes>
          <WriteActionModuleType ID="MyMP.OperationalWorkflows.MyWorkflow.WA" Accessibility="Internal" Batching="true">
            <Configuration>
              <xsd:element minOccurs="1" name="TimeoutSeconds" type="xsd:integer" xmlns:xsd="http://www.w3.org/2001/XMLSchema" />
            </Configuration>
            <OverrideableParameters>
              <OverrideableParameter ID="TimeoutSeconds" Selector="$Config/TimeoutSeconds$" ParameterType="int" />
            </OverrideableParameters>
            <ModuleImplementation>
              <Composite>
                <MemberModules>
                  <WriteAction ID="WA" TypeID="Windows!Microsoft.Windows.PowerShellWriteAction">
                    <!--
                    ###########################
                    Enter actual script name here.
                    ###########################
                    -->
                    <ScriptName>MyScript.ps1</ScriptName>
                    <ScriptBody>
                      
    $oAPI = New-Object -comObject "MOM.ScriptAPI"
    $oAPI.LogScriptEvent("MyWorkflow.ps1",555,0,"Update Proxy Script started.")
    
    try {
        Import-Module OperationsManager
        $a = Get-Module -ListAvailable
        $b = whoami
        $oAPI.LogScriptEvent("MyWorkflow.ps1",555,0,$a -join ", ")
        $oAPI.LogScriptEvent("MyWorkflow.ps1",555,0,$b)
    }
    catch [system.exception] {
    $oAPI.LogScriptEvent("MyWorkflow.ps1",555,0,$error)
    }
     
                    </ScriptBody>
                    <!--
                    ###########################
                    In this section, modify the attributes based on your needs. Ensure the
                    Base attribute matches the application you are modeling.
                    More information can be found in the Management Pack Development Kit: 
                    http://msdn.microsoft.com/en-us/library/ee533867.aspx
                    ###########################
                    <Parameters>
                      <Parameter>
                        <Name>YourScriptParamter1</Name>
                        <Value>$Config/YourScriptParamter1$</Value>
                      </Parameter>
                      <Parameter>
                        <Name>YourScriptParamter2</Name>
                        <Value>$Config/YourScriptParamter2$</Value>
                      </Parameter>
                    </Parameters>
                    -->
                    <TimeoutSeconds>$Config/TimeoutSeconds$</TimeoutSeconds>
                  </WriteAction>
                </MemberModules>
                <Composition>
                  <Node ID="WA" />
                </Composition>
              </Composite>
            </ModuleImplementation>
            <InputType>System!System.BaseData</InputType>
          </WriteActionModuleType>
        </ModuleTypes>
      </TypeDefinitions>
      <Monitoring>
        <Rules>
          <Rule ID="MyMP.OperationalWorkflows.MyWorkflow.Rule" Enabled="true" Target="SC!Microsoft.SystemCenter.RootManagementServer" ConfirmDelivery="true" Remotable="true" Priority="Normal" DiscardLevel="100">
            <Category>Operations</Category>
            <DataSources>
              <DataSource ID="Schedule" TypeID="System!System.SimpleScheduler">
                <!--update default interval-->
                <IntervalSeconds>86400</IntervalSeconds>
                <SyncTime />
              </DataSource>
            </DataSources>
            <WriteActions>
              <WriteAction ID="WA" TypeID="MyMP.OperationalWorkflows.MyWorkflow.WA">
                <TimeoutSeconds>900</TimeoutSeconds>
              </WriteAction>
            </WriteActions>
          </Rule>
        </Rules>
      </Monitoring>
      <LanguagePacks>
        <LanguagePack ID="ENU" IsDefault="true">
          <DisplayStrings>
            <DisplayString ElementID="MyMP.OperationalWorkflows">
              <Name>My MP - Operational Workflows</Name>
              <Description>This management pack contains workflows for SCOM operational and administrative purposes.</Description>
            </DisplayString>
            <DisplayString ElementID="MyMP.OperationalWorkflows.MyWorkflow.Rule">
              <Name>My Workflow</Name>
              <Description>This rule runs a powershell script.</Description>
            </DisplayString>
            <DisplayString ElementID="MyMP.OperationalWorkflows.MyWorkflow.WA" SubElementID="WA">
              <Name>Write action.</Name>
            </DisplayString>
            <DisplayString ElementID="MyMP.OperationalWorkflows.UpdateAgentProxyProfile">
              <Name>My MP - Operational Workflows</Name>
              <Description>This Run As profile.</Description>
            </DisplayString>
          </DisplayStrings>
          <KnowledgeArticles></KnowledgeArticles>
        </LanguagePack>
      </LanguagePacks>
    </ManagementPack>

    .

    Jonathan Almquist | SCOMskills, LLC (http://scomskills.com)

    Thursday, February 7, 2013 4:27 PM
    Moderator
  • Try importing it using the psm file:
    Import-Module "C:\Program Files\System Center 2012\Operations Manager\Powershell\OperationsManager\OperationsManager.psm1"

    Thursday, February 7, 2013 4:56 PM
  • We were on the same page, Andreas. I did this and it worked. Why the module didn't import properly without the full path is strange. Would like to find a full resolution to this, since this will basically need to be a parameter to the OperationsManager.psm1 file in custom workflows... :(

    Thanks all for the pointers.


    Jonathan Almquist | SCOMskills, LLC (http://scomskills.com)

    Thursday, February 7, 2013 5:08 PM
    Moderator
  • I guess this has to do with search directories and that inside the PowerShell module this folder isn't part of them.
    Monday, February 11, 2013 12:39 PM
  • @Jonathan,

    Have you found a resolution for this? I just ran up against this using Orchestrator + Ops.

    Thanks,


    Jeffrey S. Patton Jeffrey S. Patton Systems Specialist, Enterprise Systems University of Kansas 1001 Sunnyside Ave. Lawrence, KS. 66045 (785) 864-0242 | http://patton-tech.com

    Monday, August 26, 2013 6:42 PM
  • No. I haven't needed to do this since that particular project, and just used the workaround posted earlier.

    Jonathan Almquist | SCOMskills, LLC (http://scomskills.com)

    Monday, August 26, 2013 8:34 PM
    Moderator