Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

We run in a Citrix/Wyse Terminal environment (200+ terminals)

All users Wyse terminals are not connected to a Domain and users log in with a local user account with no password (there is another Administrator account password protected which we use to make changes).

By default our Wyse terminal build has Windows Firewall enabled + File and Print Sharing disabled/un-ticked.

We have a requirement to reboot all terminals every night and have a PsExec script scheduled to run against all network terminals.

The problem is ANY PsExec cmd will not execute against a remote ip address/machine unless either a) that machines Firewall is disabled or b) File and Print Sharing is enabled - so it can access the Admin$ share.

Short of having to manually go around every machine where the firewall is on and disabling it/allowing File and Print sharing, is there anyway to remotely enable F&P sharing either by some other non PsExec cmd or remotely add a registry entry (bear in mind GPo cannot be used as the machines are not on the network)

We have tried passing through the -u and -p switch with local user account and pc name when running the PsExec command but no luck.

As soon as I enable F&P Sharing or disable the firewall completely on a test machine the remote PsExec script works.

share|improve this question
    
I guess we ultimately just need to allow port 445 which is disabled within File and Printer sharing. –  Daniel Aug 30 '13 at 3:09
    
Or is there a way to manipulate the local machines GPo –  Daniel Aug 30 '13 at 3:12
    
What version/edition of Windows do the terminals run? –  joeqwerty Aug 30 '13 at 3:18
    
Good point, the local terminals are running on Windows XP embedded –  Daniel Aug 30 '13 at 3:18

1 Answer 1

You need to allow TCP 445 connections from the management machine(s) that are trying to connect to these machines with PSTools.

You don't need to open it up to everyone, but you do need to open it up to those machines.

share|improve this answer
    
If I understand correctly you are saying the server I am running the script from needs to have Port 445 open not the machine I am trying to run the PSExec command against? I tried this however I get the same issue it will not allow the PSExec command to run until I open Port 445 on the target. Also for reference the server I opened port 445 on had firewall off anyway so 445 would have been open by default I believe –  Daniel Sep 2 '13 at 1:04
    
The machine you are trying to run the commands on (running PSExec against, in your words) must have file and print turned on, and it's firewall must allow connections to 445 inbound from the server that is running the script. (but not necessarily anywhere else). –  Rod MacPherson Sep 3 '13 at 1:51
    
yes I understand what you are saying and know this is what is needed already (see my original post and comments). What I am asking is, if there is a way to enable Port 445 remotely on a target machine/s where port 445 is not enabled. Port 445 is needed to run a PSExec command so it is a catch-22 however I am trying to establish if there is any other way to enable this port remotely without having to use PSExec based on the original scenario outlined, other than physically visiting all clients. –  Daniel Sep 3 '13 at 2:30
    
is PowerShell remoting (WinRM) enabled? You could try using Powershell if it is. –  Rod MacPherson Sep 4 '13 at 2:20

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.