Skip to main content

mom: execute a command or batch file...

i was fiddling around with using this to issue a stop/start sequence on a service under a given condition. the stop/start stuff was pretty easy, but the response execution was a little baffling.

i found that mysterious "use windows command interpreter (not recommended)" dialog is required (i didn't put the parenthesis around not recommended. that was microsoft's doing). anyway, that's the first part. i'll get to that in a minute.

so how do you execute commands in a sequence? the answer is, i don't know. i don't know if it's possible. i don't know if it happens if you order it right. if you notice, the dialog doesn't supply an "up/down" button to move the commands around to sequence them. you'd have to create them in order. even then, does it execute this way? dunno.

the easy way around this is to use a double ampersand. so in order to stop and start the dhcp service, for example, you'd issue this command:

net stop dhcpserver && net start dhcpserver.

this will issue a stop control, wait for the command to finish successfully, then execute a start control. you can do this in a command shell and see how it runs.  (more detail on conditional executions here, if you’re interested.)  back to the first part, in order to execute things like this, you need that (not recommended) setting. otherwise, you'll see something like this in the event log:

Microsoft Operations Manager was unable to create a process to run a batch response.

User Command: %windir%\system32\cmd.exe /c
User Arguments: "net stop dhcpserver && net start dhcpserver"
Command executed: C:\WINDOWS\system32\cmd.exe /c "net stop dhcpserver && net start...
Error details: 3:The system cannot find the path specified.

believe me, i tried all kinds of ways to get this to work, including specifying a variable %windir% in the command line itself to call cmd.exe /c, specifying initial directory, putting the item directly on the command line... none of it worked. the interesting question is why the use windows command interpreter is (not recommended). according to this statement...
Using the Windows command interpreter is not recommended as it exposes customers to command line injection vulnerabilities whereby maliciously constructed instrumentation data could cause the execution of arbitrary code. By separating the application name from the parameters passed to it, secure invocation mitigates the command line injection vulnerability.
there is no secure invocation (calling a program or procedure) when you use this method. what am i trying to say? use a batch or scripted response where possible. it's easy to do this for starting/stopping services. i suppose you could consider this an interim approach and definitely not something to use on secured machines or dmz servers.

Comments

  1. Thanks for the info on the &&. Fortunately, I've already run into the issues with not using the command interpreter. The issue here is a fuzy description in that response dialog that is hopefully corrected in SCOM 2007.

    The trick is to think of the application field as the run line. So your example (fully qualified, which is more thourough than mine) should only include cmd.exe. Just the application.

    Then the command arguements start with /c... This one had me for a while until I ran across someone elses blogs to clarify. Thanks to the && I am able to stop IIS, Stop then restart my application and then restart IIS all in order; all waiting for the previous command to return before starting.

    Erik

    ReplyDelete
  2. Thank you very much! I wasted a lot time trying to find a way to run this "net stop" / "net start" in order...

    ReplyDelete

Post a Comment

Popular posts from this blog

using preloadpkgonsite.exe to stage compressed copies to child site distribution points

UPDATE: john marcum sent me a kind email to let me know about a problem he ran into with preloadpkgonsite.exe in the new SCCM Toolkit V2 where under certain conditions, packages will not uncompress.  if you are using the v2 toolkit, PLEASE read this blog post before proceeding.   here’s a scenario that came up on the mssms@lists.myitforum.com mailing list. when confronted with a situation of large packages and wan links, it’s generally best to get the data to the other location without going over the wire. in this case, 75gb. :/ the “how” you get the files there is really not the most important thing to worry about. once they’re there and moved to the appropriate location, preloadpkgonsite.exe is required to install the compressed source files. once done, a status message goes back to the parent server which should stop the upstream server from copying the package source files over the wan to the child site. anyway, if it’s a relatively small amount of packages, you can

How to Identify Applications Using Your Domain Controller

Problem Everyone has been through it. We've all had to retire or replace a domain controller at some point in our checkered collective experiences. While AD provides very intelligent high availability, some applications are just plain dumb. They do not observe site awareness or participate in locating a domain controller. All they want is the name or IP of one domain controller which gets hardcoded in a configuration file somewhere, deeply embedded in some file folder or setting that you are never going to find. How do you look at a DC and decide which applications might be doing it? Packet trace? Logs? Shut it down and wait for screaming? It seems very tedious and nearly impossible. Potential Solution Obviously I wouldn't even bother posting this if I hadn't run across something interesting. :) I ran across something in draftcalled Domain Controller Isolation. Since it's in draft, I don't know that it's published yet. HOWEVER, the concept is based off

sccm: content hash fails to match

back in 2008, I wrote up a little thing about how distribution manager fails to send a package to a distribution point . even though a lot of what I wrote that for was the failure of packages to get delivered to child sites, the result was pretty much the same. when the client tries to run the advertisement with an old package, the result was a failure because of content mismatch. I went through an ordeal recently capturing these exact kinds of failures and corrected quite a number of problems with these packages. the resulting blog post is my effort to capture how these problems were resolved. if nothing else, it's a basic checklist of things you can use.   DETECTION status messages take a look at your status messages. this has to be the easiest way to determine where these problems exist. unfortunately, it requires that a client is already experiencing problems. there are client logs you can examine as well such as cas, but I wasn't even sure I was going to have enough m