Yami learns Powershell
-
I have no idea what I'm doing and it's awesome >.>
So I have an RDP file, connecting to SERVERNAME using Username and Password.Once in that remote desktop session, my sole task has been reduced to clicking on a batch file, typing in a single parameter, and watching to make sure it runs successfully.
I'm converting this to powershell. My understanding is that to connect, I need to run
Enter-PSSession -ComputerName SERVERNAME -Credential Username
Or maybe
Enter-PSSession -ComputerName SERVERNAME -Credential Username@SERVERNAME
But I'm getting
Enter-PSSession : Connecting to remote server failed with the following error message : Logon failure: unknown user name or bad password. For more information, see the about_Remote_Troubleshooting Help topic.
I've verified a half a dozen times that I'm using the same credential I do when I connect via RDP. Is there some gotcha I'm not realizing?
-
Have you tried
Enter-PSSession -ComputerName SERVERNAME -Credential SERVERNAME\Username
?
-
Or if it's on a domain then
-Credential DOMAIN\Username
If it's on a domain and it's a domain user then
SERVERNAME\Username
orUsername@SERVERNAME
willobviouslyfail.If it's on that server you shouldn't need to specify
SERVERNAME
in the credentials anyway.
edit: Not obviously. Dick move. Fair point @blakeyrat.
-
I was under the impression that it was a local account. I could be mistaken. I tried DOMAIN\Username and no change.
Oh! SERVERNAME\Username got a different failure message!
Enter-PSSession : Connecting to remote server failed with the following error message : WinRM cannot process the request. The following error occured while using Kerberos authentication: There are currently no logon servers available to service the logon request. Possible causes are: -The user name or password specified are invalid. -Kerberos is used when no authentication method and no user name are specified. -Kerberos accepts domain user names, but not local user names.
So I assume I want to use not-Kerberos for Authentication? Or maybe I'm just wrong about the credentials
Verified: the credentials are definitely local to the server.
But I can't use Basic or Digest because it's unencrypted and that's disabled. Which makes sense! How do I encrypt it?
-
I hate backslashes. Is it somehow getting interpreted as escaping the next character?
-
Um probably not? It says Kerberos can't process local credentials, but I can't use Basic or Digest because it'd send the password in the clear, and Negotiate utterly failed because
The WinRM client cannot process the request. If the authentication scheme is different from Kerberos, or if the client computer is not joined to a domain, then HTTPS transport must be used or the destination machine must be added to the TrustedHosts configuration setting.
so I guess I need https?
-
Did you try
-Credential Username
?
-
Did you try -Credential Username ?
First thing I tried.
Okay, so if I add -UseSSL, it says
Enter-PSSession : Connecting to remote server failed with the following error message : The client cannot connect to the destination specified in the request. Verify that the service on the destination is running and is accepting requests . Consult the logs and documentation for the WS-Management service running on the destination, most commonly IIS or WinRM.
This is a web server, it can handle SSL (certs and whatnot are set up)....
-
Is
WS-Management
running?
-
Locally or remotely?
-
Remotely.
Consult the logs and documentation for the WS-Management service running on the destination
is why I'm asking that btw... :)
-
It occurs to me: This is a Windows 2003 server. I don't think it has Powershell. Is that the problem?
-
Well since you're trying to start a remote PS session, that may make it slightly difficult, yes :)
-
Have you checked the Event Viewer from the remote server to see why if there's anything helpful there?
-
Yes
-
or the destination machine must be added to the TrustedHosts configuration setting.
winrm set winrm/config/client ‘@{TrustedHosts="SERVERNAME"}’
Then try connecting with Negotiate.
-
OKAY SO.
Another server in my list is updated to 2008 and has powershell. It also authenticates using my AD credentials, the same ones I'm using on the local machine. So that ought to be an easier place to start, since we're upgrading all these 2003 servers to 2008-or-Linux anyway (I assume this one has the standard loadout for 2008).
However, l still get the same issue, and since I don't have admin rights, I can't run quickconfig.
Is this whole project a nonstarter? I think it might be.
-
Try specifying Kerberos explicitly with a domain login?
-
Enter-PSSession : Connecting to remote server failed with the following error message : The client cannot connect to the destination specified in the request. Verify that the service on the destination is running and is accepting requests
-
And you can connect to the server otherwise?
You've not typo'd the server name or something?I've never had this much problem - this stuff normally just works but then I'm admin on all of our servers so maybe that simplies it.
-
yeah, I have 0 control over the servers but 100% responsibility for executing this task on all of them every week sometimes multiple times.
So... yeah.
We've never done it this way before, so it might just not be set up right. Look, is Poweshell not the way to go here? The guy who handed this duty off to me suggested it over the following suggestions:
a. Option A: Install SSH onto the Windows boxes. Do everything via SSH. b. Option B: Net Use the various hard drives from a single machine. Re-write the batch file to do all servers at once instead of operating on one server at a time. c. Option C: Edit the saved RDP sessions to include kicking off a command. Edit the batch file to take in an argument instead of interactive input. Run the saved RDP sessions using mstsc. Would have to be updated by the script to update the parameter saved in the RDP file
A is politically dicey, B is messier than it sounds (there's a LOT of logic in the batch file), and C is TRWTF. So he suggested option D, do this with Powershell. Maybe I use Powershell to run mstsc -- can I start a session based on a saved rdp file, and then execute commands through it this way?
-
C sounds the most obvious to me. Why do you say it's TRWTF?
You could also then bulk-run all the RDP connections at once in another PowerShell, or batch script.
-
It doesn't sound over-engineered to the point of absurdity to you? Maybe my gut feeling is out of tune.
-
A is politically dicey
If Powershell is giving you this much trouble, I say screw the politibollocks and just get SSH on there
-
What's wrong with C? That's effectively "use Powershell to run mstsc..." anyway.
If you can't get Powershell working, that's the way forwards.
-
You could try this too...
-
Maybe I didn't highlight the part where I'd have to edit the RDP file every week in the script to pass in the correct parameter well enough? That's the part where it starts to smell funky to me.
-
I admit it's less ideal than remote-controlling the servers using PowerShell or VBScript or whatever, but it also seems easy-to-implement. Especially if your servers don't support remote scripted logins for whatever reason.
You could implement that in a few hours. Waiting on IT to install shit on the servers could take days.
-
Haven't fully read the thread but:
Is there a reason you can't convert the batch file to a VBScript and create a scheduled task to launch it?
-
Is there a reason you can't convert the batch file to a VBScript and create a scheduled task to launch it?
From two posts behind:
Maybe I didn't highlight the part where I'd have to edit the RDP file every week in the script to pass in the correct parameter well enough?
-
It's not a scheduled task thing, it's a "when people tell me to" thing. It's just a ton of clicking at the moment. I want to hook it up to my CI server so it can be triggered by the people who are telling me to do it so I can stop doing it.
-
From two posts behind
@MathNerdCNU said:Haven't fully read the thread but
<wheeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
-
PSExec might be the way to go here. I can make a batch file that takes in the parameter once and then PSExecs to all the machines to run their batch file with the command.
-
It's not a scheduled task thing, it's a "when people tell me to" thing. It's just a ton of clicking at the moment. I want to hook it up to my CI server so it can be triggered by the people who are telling me to do it so I can stop doing it.
Possible alternative: throw together a quickie WinForms app? Stick a textbox and a button on a form, and then wire up the button to do the magic.
-
Well if you wanna go into full WTF territory, you could set up a quick-and-dirty Amazon S3 server, put your script argument in it, have each server run a quick-and-dirty script to download the argument, run the command, then email/whatever the results to you. Put it in a scheduled task.
-
We don't use .NET here. For anything (except Sharepoint, the Sharepoint guy has an exemption)
-
PowerShell requires .NET. FYI.
You might just have hit upon the real problem here.
-
We don't use .NET here
PowerShell is just another language that's built on .NET. Not to mention all those Win2008 servers will have the full .NET 3.5 Framework installed, since they have PowerShell installed.
-
Fair enough, I always forget that. The server team likes powershell for whatever reason, but the devs hate .NET in general, and have almost no expertise with it. I'm kind of caught in the middle between teams.
-
the devs hate .NET in general
Why?
@Yamikuronue said:and have almost no expertise with it
Ah. Prejudice.In all seriousness though, and obviously without knowing the full details of your systems I can't say for sure, but if you're having this much trouble with PowerShell, a quickie C# app could be the least y alternative.
-
We dislike Visual Studio and apparently have had bad experiences with people who don't know how to program but are experts in getting VS to write their code for them in the past. I personally am fine with C#, have used ASP.net (with varying levels of success), and so on, but I don't want to write something only I can maintain because the whole point is getting this off my plate.
-
The server team likes powershell
If anybody else is using it then ask them? For all you know you are simply bumping into some security restriction where your user isn't allowed to remotely execute those scripts.
-
PSExec is giving me
C:\PSTools>C:\PSTools\psexec \\servername -u username -p password "C:\full\path\too\file.bat" -accep teula Couldn't access servername: Access is denied.
-
For all you know you are simply bumping into some security restriction where your user isn't allowed to remotely execute those scripts.
yeah, I may need to get back to the guy who suggested powershell and ask him. I was hoping to be able to solve this :/
Crap. That was the three hours I set aside for doing this today >.>
-
Use full username/domain combo, so
[MACHINE]\[USER]
- the server is probably defaulting to the domain which will fail
-
yeah, I may need to get back to the guy who suggested powershell and ask him. I was hoping to be able to solve this :/
The script works when you run it from inside a RDP session but throws authentication errors when you want it to connect on it's own ...
-
Access still denied.
The script works when you run it from inside a RDP session but throws authentication errors when you want it to connect on it's own ...
huh? Maybe I need more caffeine but I'm not understanding what you're saying here. I can't get to the machine in order to execute the batch file that's stored there (that he wrote)
-
Hmm, does the task you're running require admin permissions, or will your AD account work?
-
does the task you're running require admin permissions, or will your AD account work?
Mu.
For each server, the credentials I have written down in my big list of credentials are sufficient to run the batch file via double-clicking on it. In some servers that's my AD account, in others it's a local account. In no case do I need to elevate (which, these are primarily Windows Server 2003 servers, so that'd be hard to do)
-
Question rephrase:
Would your AD account be able to run this task?