PowerShell

Hi all,

Looking for some help with PowerShell.

We have a script that runs and allows us to perform various tasks such as creating mailboxes on certain mailbox databases, create new users accounts etc.

However the problem is, the script won't work on my machine. It will work on a colleagues machine while logged in as myself and if I log into the server directly and run the script, it works fine.

I've checked and the particular line that's causing the script to fall over is -

Code:

---

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri http://servername/PowerShell/ -Authentication Kerberos

---

The error is - New-PSSession : [servername] Connecting to remote server servername failed with the following error message : No mapping for the Unicode character exists in the target multi-byte code page. For more information, see the about_Remote_Troubleshooting Help topic.
At line:1 char:12

The character its referring to is the "N".

I've Googled until my fingers feel like they are falling off and have spoken to the guy who wrote the script and we can't pin point the cause.

Have also checked the configurations between our machines and they *appear* to be the same, both built from the same image.

Any help or points would be appreciated.

Thanks,

Are you sure it’s the ‘n’? Counting in after the $ prompt, the 12th character is the ‘e’. However I don’t know if whitespace counts as a character or not - in which case it is the ‘-‘ character.

Maybe it is actually telling you exactly what the error message says:
Somehow what looks like one character is actually a Unicode character which can be translated?

Anyway, from your error I though it would be a character in the actual connection string?

Quote:

---

Originally Posted by peterb

Are you sure it’s the ‘n’? Counting in after the $ prompt, the 12th character is the ‘e’. However I don’t know if whitespace counts as a character or not - in which case it is the ‘-‘ character.

---

?

Unless I'm being dumb the $ is counted?

$Session = New-PSSession

1	2	3	4	5	6	7	8	9	10	11	12
$	S	e	s	s	i	o	n		=		N

Quote:

---

Originally Posted by kompukare

Maybe it is actually telling you exactly what the error message says:
Somehow what looks like one character is actually a Unicode character which can be translated?

Anyway, from your error I though it would be a character in the actual connection string?

---

..the connection string is what I posted.
That exact string works on a server and from my colleagues machine logged in as myself (who wrote it) yet refuses to work on mine.
I've even went through the process of re-writing the entire thing

I'm fairly sure its something on my machine / something the server is receiving from my machine, but for the life of me, I can't find it..

Quote:

---

Originally Posted by Disturbedguy

..the connection string is what I posted.
That exact string works on a server and from my colleagues machine logged in as myself (who wrote it) yet refuses to work on mine.
I've even went through the process of re-writing the entire thing

I'm fairly sure its something on my machine / something the server is receiving from my machine, but for the life of me, I can't find it..

---

Well, of course my speculation is that it isn't the exact same string.
That one either is Unicode (UTF-8 or UTF-16) and the other is not.
I would try using Notepad++ and saving the scrip as ANSI, UTF-8 and UTF-16 in turn (use a different filename) and see if any of those work.
Your example connection string really doesn't have anything which ANSI couldn't handle.

Iexpect you found this

https://winscp.net/eng/docs/message_...ng_for_unicode

but it does indicate a character in the wrong code format, as Kompucare says

(Sorry - I read the $ as prompt - not as a flag for a string variable in my earlier post :) )

Quote:

---

Originally Posted by kompukare

Well, of course my speculation is that it isn't the exact same string.
That one either is Unicode (UTF-8 or UTF-16) and the other is not.
I would try using Notepad++ and saving the scrip as ANSI, UTF-8 and UTF-16 in turn (use a different filename) and see if any of those work.
Your example connection string really doesn't have anything which ANSI couldn't handle.

---

It is the exact string though. The script is saved in a shared area and I copied it off to run from my machine which failed, but ran the same script from my colleagues machine with me logged in and the server and it ran fine.

Tried the Notepad++ thing and Peter's suggestion and neither have worked.

This may seem a little off the wall, but run the following from an elevated command prompt:

netsh winhttp show proxy

If it returns a proxy value as opposed to Direct Access (No Proxy) run:

netsh winhttp reset proxy

and then try again.

This may seem a bit basic, but have you loaded Exchange Tools on your PC?

Edit - and have you pointed your powershell to use the tools?

Have a look here:

https://www.interfacett.com/blogs/ho...in-powershell/

Quote:

---

Originally Posted by GuruNot

This may seem a little off the wall, but run the following from an elevated command prompt:

netsh winhttp show proxy

If it returns a proxy value as opposed to Direct Access (No Proxy) run:

netsh winhttp reset proxy

and then try again.

---

Why would I reset my proxy, for something that is an encoding error?

Quote:

---

Originally Posted by Disturbedguy

Why would I reset my proxy, for something that is an encoding error?

---

The reason why I suggested clearing your winhttp settings is that it might not be an encoding error.

Certain applications such as ftp.exe , mstsc.exe and powershell.exe can be affected by your WinHTTP configuration.

If your winhttp output shows a proxy server with no exceptions then all http(s) traffic that is using winhttp will be sent to your proxy server. If there is no route from the proxy to the server you are trying to connect to (http://servername/) then the connection/session will fail.

In your powershell you are referencing your server using just its hostname, so even if your winhttp settings have your local domain excluded ie domain.local , it is not going to match the exception and that traffic will still be sent to the proxy.

If you have your domain listed in your winhttp exceptions, then modify your script to use the fqdn , ie: servername.domain.local , then it would match the exceptions and be sent direct to the server instead of via the proxy. You could also jsut add the hostname to your exceptions.

Assuming your proxy settings are pushed via GPO and therefore in IE, you can put them back in to winhttp using:

netsh winhttp import proxy source=ie

EDIT: One other thought, your could run tcpview whilst running your script to see if it is trying to connect to your proxy as opposed to direct to the server.

Quote:

---

Originally Posted by GuruNot

The reason why I suggested clearing your winhttp settings is that it might not be an encoding error.

---

I have been thinking more about the initial statement I made, I suppose it actually could be classified as an encoding error.

Powershell would be getting an incorrect response from the proxy server instead of the expected response from the Exchange server.