Need Help to create another PS instance

PowerShell Help
1

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.

2

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.
https://www.penflip.com/powershellorg/secrets-of-powershell-remoting/blob/master/powershell-remoting-and-security.txt

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 http://blogs.msdn.com/b/powershell/archive/2013/12/16/powershell-security-best-practices.aspx and go over the slides.

From about_Remote_FAQ: https://technet.microsoft.com/en-us/library/hh847845.aspx

IS WINDOWS POWERSHELL REMOTING SECURE?

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.

From http://www.jasonhelmick.com/2011/07/27/enabling-powershell-remoting-in-your-environment/

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 (https://msdn.microsoft.com/en-us/library/dd357801.aspx) 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.

Regards
Daniel