Remotely invoking shutdown on a Windows machine, as you're describing requires two-way communication between the host initiating the shutdown and the host being shut down. Authentication is "baked in" to the protocol, so you'll also have to get the host initiating the shutdown to authenticate properly.
A simple script to remotely invoke the shutdown on a remote non-domain-joined computer would be as follows:
net use \\x.x.x.x\ipc$ /user:administrator password
shutdown -s -t 10 -f -m \\x.x.x.x
met ise \\x.x.x.x\ipc$ /delete
Substitute in the IP address of the remote server for "x.x.x.x" and the local Administrator username and password on the remote server on the first net use line.
Relying on "seeing" computers in "My Network Places" doesn't, unfortunately, tell you too much about what kinds of traffic are permitted between machines.
I just sniffed such an exchange between a Windows Server 2003 machine and a Windows 2000 Server machine (which, funnily enough, is running an old 2003-era Cisco CallManager 3 installation for one of my Customers) and performed the shutdown using the script above (though I rebooted their server, rather than shutting it down-- the packet exchange is the same). I observed that TCP ports 139 and 445 were used to move the traffic. I'd guess that if I had only port 139 open it'd probably still work, but you'd have to try that to see.
If you want to use the name of the CallManager server, rather than the IP address, in the shutdown script then you'll need to have either NetBIOS or DNS-based name resolution working.
Edit:
That's not so much a "Windows problem" as a hardware power-management problem, typically. You may have the wrong HAL installed, or the BIOS power management support may be turned off.
You can try adding the REG_SZ value "PowerdownAfterShutdown" in "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" and setting it to "1" to see if it has an effect on the behavior.
Check the BIOS and be sure that power-management functionality is enabled.
[wiped large answer, summarizing for clarity. See edit-history for sordid tale.]
There is a single well-known SID for the local system. It is S-1-5-18, as you found from that KB article. This SID returns multiple names when asked to be dereferenced. The 'cacls' command-line command (XP) shows this as "NT Authority\SYSTEM". The 'icacls' command-line command (Vista/Win7) also shows this as "NT Authority\SYSTEM". The GUI tools in Windows Explorer show this as "SYSTEM". When you're configuring a Service to run, this is shown as "Local System".
Three names, one SID.
In Workgroups, the SID only has a meaning on the local workstation. When accessing another workstation, the SID is not transferred just the name. The 'Local System' can not access any other systems.
In Domains, the Relative ID is what allows the Machine Account access to resources not local to that one machine. This is the ID stored in Active Directory, and is used as a security principle by all domain-connected machines. This ID is not S-1-5-18. It is in the form of S-1-5-21[domainSID]-[random].
Configuring a service as "Local Service" tells the service to log on locally to the workstation as S-1-5-18. It will not have any Domain credentials of any kind.
Configuring a service as "Network Service" or "NT Authority\NetworkService" tells the service to log on to the domain as that machine's domain account, and will have access to Domain resources. The Windows XP Service Configurator does not have the ability to select "Network Service" as a login type. The SQL Setup program might.
"Network Service" can do everything "Local System" can, as well as access Domain resources.
"Network Service" has no meaning in a Workgroup context.
In short:
NT Authority\System = Local System = SYSTEM = S-1-5-18
If you need your service to access resources not located on that machine, you need to either:
- Configure it as a Service using a dedicated login user
- Configure it as a Service using "Network Service" and belong to a domain
Best Answer
Yes you can do this without a domain setup. The credentials that you supply for the shutdown command have to exist on the remote computer. To make it easy, you'll have to make sure that at least one account with the same username and password exists on each computer that you're going to run the command against.
Do the remote PCs have their firewall turned on? If so, turn off the firewall for one of them and see if the command works. If so, you've narrowed it down to a firewall issue and you'll need to open the correct ports (and probably want to narrow it down to only accepting traffic on that port from one IP address, namely your workstation's address).
You might find it easier and more powerful to use the Windows SysInternals tool PSShutdown.exe. That way you can maintain a list of PCs that you want to shutdown in a text file and merely edit that file when you want to add or remove the effected computers.
Furthermore, you might want to look into the Edison power management utlity. It can automate quite a bit of power options for you and save some cash for the office.