Sunday, December 23, 2012

Getting more detail from Azure PowerShell Cmdlet 400 errors

Some of the Azure PowerShell Cmdlets return less than useful errors:
New-AzureDeployment : The remote server returned an unexpected response: (400) Bad Request.
At line:1 char:5
+     New-AzureDeployment -Slot $slot -Package "$root\NewSite.Azure\bin\Release\ap ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : CloseError: (:) [New-AzureDeployment], ProtocolException
    + FullyQualifiedErrorId : Microsoft.WindowsAzure.Management.ServiceManagement.HostedServices.NewAzureDeploymentCommand
The way to get more detailed information is on this blog:
(New-Object System.IO.StreamReader($Error[0].Exception.InnerException.Response.GetResponseStream())).ReadToEnd()
I have simply formatted this into a useful PowerShell oneliner. Note that this command can only be run once. The problem in my case was that I had changed my storage account to camel case, but it must be all lower case.
<Error xmlns="http://schemas.microsoft.com/windowsazure" xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
  <Code>BadRequest</Code>
  <Message>The name is not a valid storage account name. Storage account names must be between 3 and 24 characters in length and use numbers and lower-case letters only.</Message>
</Error>

Friday, December 14, 2012

Checking if a TCP port is listening in PowerShell (TCP Ping)

In older versions of Windows, the telnet command could be used to test a TCP connection to another machine. However, this is not installed by default on newer versions of the O/S. The solution is to use a .NET class from PowerShell:
New-Object System.Net.Sockets.TcpClient machinename, 1337

Error configuring CredSSP

I was trying to configure CredSSP from a Windows 8 machine to Windows Server 2008 R2, but ran into the issue below:
C:\Windows\system32> Enable-WSManCredSSP -Role Client -DelegateComputer remotepc

CredSSP Authentication Configuration for WS-Management
CredSSP authentication allows the user credentials on this computer to be sent to a remote computer. If you use CredSSP
 authentication for a connection to a malicious or compromised computer, that computer will have access to your user
name and password. For more information, see the Enable-WSManCredSSP Help topic.
Do you want to enable CredSSP authentication?
[Y] Yes  [N] No  [S] Suspend  [?] Help (default is "Y"):
Enable-WSManCredSSP : 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. If the destination is the WinRM
service, run the following command on the destination to analyze and configure the WinRM service: "winrm quickconfig".

At line:1 char:1
+ Enable-WSManCredSSP -Role Client -DelegateComputer COMPUTER
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (System.String[]:String[]) [Enable-WSManCredSSP], InvalidOperationExce
   ption
    + FullyQualifiedErrorId : WsManError,Microsoft.WSMan.Management.EnableWSManCredSSPCommand
I was baffled for a while, since WinRM was correctly configured on the remote PC. However, procmon showed that the local command was trying to connect to port 47001 on my local machine, which is the local WinRM service. After starting my local WinRM service, everything worked correctly.

Wednesday, December 12, 2012

Git client configuration

This is the Git configuration I use for my local repositories.
[core]
 autocrlf = false
[push]
 default = simple
[rerere]
 enabled = true
[diff]
 tool = p4merge
[difftool "p4merge"]
 cmd = p4merge \"$LOCAL\" \"$REMOTE\"
[merge]
 defaultToUpstream = true
 tool = p4merge
[mergetool "p4merge"]
 cmd = p4merge \"$BASE\" \"$LOCAL\" \"$REMOTE\" \"$MERGED\"
 keepTemporaries = false
 trustExitCode = false
 keepBackup = false
[gc]
 auto = 0