Need Help to create another PS instance

This topic contains 1 reply, has 2 voices, and was last updated by Profile photo of Daniel Krebs Daniel Krebs 1 year, 5 months ago.

  • Author
  • #25320
    Profile photo of

    Hi All,
    I am tired a lot finding a solution for my issue. I have developed all my logic and all now I need is to run ths script simultaneously for several computers. I thought to implement this by jobs but unfortunately I realized from previous QA its not so easy to implement -AsJob feature to custom functions/modules.

    My complete requirement !!

    I have several DAGs in exchange environment, lets say 50 DAGs. I want to reboot all first nodes from each 50 DAGs at one time. Once after successful reboot of all first nodes then I will have proceed with second node and so forth. Before and after reboot I must do some health checks and log all results.

    Up to what I finished my coding?
    1. The first attachment will validate all prerequisites and returns the node names those should reboot in first batch (each first node from 50 DAGs)
    2. The second attachment will perform health checks.

    Where I struck?
    1. In my prod environment PS remoting is not enabled and cannot be enabled.
    2. I don't know how run each batch computer' s health checks simultaniously like, -AsJob or by calling the script along with prarameters in another Power Shell window.
    3. I am even OK if I can open each computer's health checks script in another PS window but I must be able to capture the outputs /logs.

    Where I run all these?
    1. I am not going to run these script on any prod servers. I will run these from regional admin servers.

    Somewhere in Google found the below code. Please suggest if I can implement.

    $command = ("notepad.exe")
    $process = [WMICLASS]"\\$ComputerName\ROOT\CIMV2:win32_process"
    $result = $process.Create($Command)

    Please some one help me to finish this project.

  • #25330
    Profile photo of Daniel Krebs
    Daniel Krebs

    Hi Vidya,

    Let's stop at your first "Where I am stuck" statement.
    1. In my prod environment PS remoting is not enabled and cannot be enabled.

    Please read this page of the Secrets of Remoting free ebook.

    You will need to reach out to whoever can approve TCP port 5985 (and 5986) to be opened from your admin servers to your prod environment and educate them about the reasons, requirements and risks. All Linux and network administrators at my company can connect to TCP port 22 (SSH) of servers and devices without questions asked. Opening TCP port 22 to all Linux servers has the same risks attached as allowing PowerShell Remoting to Windows servers.

    It is crucial for Windows management to get at least TCP port 5985 (Remoting) approved and opened in your network firewalls.

    Watch the Channel 9 video linked here and go over the slides.

    From about_Remote_FAQ:


    When you connect to a remote computer, the system uses the user
    name and password credentials on the local computer or the credentials
    that you supply in the command to log you in to the remote computer.
    The credentials and the rest of the transmission are encrypted.

    To add additional protection, you can configure the remote computer
    to use Secure Sockets Layer (SSL) instead of HTTP to listen for
    Windows Remote Management (WinRM) requests. Then, users can use
    the UseSSL parameters of the Invoke-Command, New-PSSession, and
    Enter-PSSession cmdlets when establishing a connection. This option
    uses the more secure HTTPS channel instead of HTTP.


    Security Concerns

    This is a tough one. The problem is this, it doesn't matter what Microsoft says, no one believes them when they say something is secure. The SecFreaks justifiably ignore Microsoft. So, how do you get your security folks to allow PowerShell Remoting?

    1. Educate – PowerShell Remoting(WinRM) uses http and https. Internally using http is most efficient and has no security issues, however when crossing Firewall boundaries, or if you're using Remoting across the Internet, then configure it for https. Simple. Easy to manage, single port of secured access with https, so the Sec guys like it. Remember, we do our banking over https. It's pretty darn secure for Admins to use for system management.
    2. Educate – Here is a link to the protocol spec ( if the Sec Guys really want to dig into it.
    3. Educate – Do you already use RDP to manage servers? Do you use it across the Internet? If so, we are talking about adding something that does the same thing, but has a better managed security! If you already use RDP, try to help the Sec guys understand that PowerShell Remoting is even easier to keep secured and managed.
    4. Educate – Soon, you're not going to have a choice anyways.


You must be logged in to reply to this topic.