How to copy files to a remote machine with powershell 5 (the easy way)

> $creds = Get-Credential
> $session = New-PSSession -ComputerName "myremotemachine.mydomain.com" -UseSSL -Credential $creds
> Copy-Item -Path "C:\my\folder\somewhere" -Destination "C:\path\on\remote\machine" -ToSession $session

Done and done. This assumes that you have PowerShell set up for PSRemoting on the remote machine with a certificate. There's plenty of other tutorials for doing that.

Enabling tests and tracking in the "Diagnostics" tab for the "Message Queueing" node in Computer Management on Windows

Thanks to a coworker, I finally know how to enable the Diagnostics for MSMQ in Computer Management on Windows so that I can better diagnose and track issues for working with MSMQ.

See this. To find it on Google, search for this: "site:msdn.microsoft.com Enable Route Tracking and Test Messages" and also see this post from the MSMQ Mighty Hero, John Breakwell.

Solving "The signature is invalid." errors on MSMQ messages in the "MSMQ, WCF and IIS: Getting them to play nice (Part 3)" series by Tom Hollander

My company has recently had need for an MSMQ-backed queueing solution, that happened to match the topology described in Tom Hollander's "MSMQ, WCF and IIS: Getting them to play nice (Part 3)" blog post. I went a first round with that piece, trying to get it to work on our network. It cost me about a week's worth of time before I had to show that I couldn't get it to work and negotiate a deferral of the last phase of the work: enabling Transactions in addition to the security on the queue. Well, this issue reared its ugly head again and I was forced back to it. This time, I was able to get it to work with much less time and effort.

The error that I kept encountering was all my messages would go straight to the System Transactional Dead Letter Queue, with the error on them "The signature was invalid".

TL;WR: There's several steps that were unique to our setup that weren't mentioned in Tom Hollander's blog post.

The extra steps that I had to implement that weren't in the blog post were (at a high level) as follows:
1) Configure MSDTC to enable XA transactions, mutual authentication, and allowing remote clients.
2) Configure both the MSMQ Server and queues to grant Full Control to the principal that was running the service.
3) Ensure that the principal that was making the request to the server had full control over its respective queues.
4) Install MSMQTriggers and MSDTC in addition to the MSMQ service, because these pieces were apparently necessary for transactions to work in the setup in the Blog post from Tom Hollander. He never explicitly states in the Blog post series that these items have to be installed. They do.

I'll publish a follow up post with steps to automate setup of all of this if I have the time.

Automating setup of keys for Release Annotations in App Insights during an automated Release

Microsoft has finally added this ability, though the documentation is not available at the time of this writing. For instructions on how to do it, see this UserVoice item for the issue :

https://visualstudio.uservoice.com/forums/357324-application-insights/suggestions/13607550-enable-creation-and-management-of-api-keys-via-pow?tracking_code=06b602f1fc962c339ed8bcf534fcdb2f#{toggle_previous_statuses}

Solving "The storage account named XXXXX already exists under the subscription" when deploying Azure Resource Group templates

I've recently run into a problem where I've been unable to deploy multiple resource groups for my applications that contain Storage Accounts. When executing the Resource Group template deployment, I get the following error:

"The storage account named XXXXX already exists under the subscription"

The underlaying cause seems to be that Microsoft fucked up backward compatibility on their API in resource group templates. Thanks to this blog post, I was able to get back up and running. The gist of the article, repeated here for posterity, is that you have to update to the latest (as of this writing) API version of 2016-01-01. For example:

{

    “$schema”: “https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#”,

    “contentVersion”: “1.0.0.0”,

    “resources”: [

      {

        “name”: “dnntest20160705”,

        “type”: “Microsoft.Storage/storageAccounts”,

        “location”: “[resourceGroup().location]”,

        “apiVersion”: “2016-01-01”,

        “dependsOn”: [ ],

        “tags”: {

          “displayName”: “MyStorageAccount”

        },

        “sku”: {

          “name”: “Standard_LRS”

        },

        “kind”: “Storage”

      }

    ]

}

Solving the dreaded MQ_ERROR_CORRUPTED_SECURITY_DATA (0xC00E0030) MSMQ error

I recently started getting a the error MQ_ERROR_CORRUPTED_SECURITY_DATA (0xC00E0030) when trying to execute tests on my development box while publishing to MSMQ queues. As indicated by the error, the cause was corrupted security data. I had recently changed my development machine from one directory over to another. Going into the MSMQ Server properties in compmgmt.msc (Computer Management) and clearing out all the certifticates for my user, renewing them and reregistering the certificates with Active Directory fixed the issue.

Switching environments, data sources, and other dynamically changeable settings in TFS Lab (on-premise) for 2013

Thanks to a post on this blog, we can access the settings inject into Lab-managed builds in TFS 2012 and 2013. Even though this is 2016 and many people are moving to the cloud with VSTS, there are still a good number of companies out there with considerable infrastructure "on-premise", and TFS can help with executing automated tests in those environments. I'm going to be building a library for helping others out with retrieving settings dynamically from TFS and I'll update my blog when it's available.

DevExpress and their licensing model suck for professional developers

If you're using a build machine, delete all of your *.licx files out of source control. Otherwise you're just asking for trouble.

Data-driven testing with MSTest via configuration-defined data sources and XML as a data source

I've done data driven testing with MSTest before. Prior to now, it's been solely with XML file data sources that have been defined inline in the [DataSource] attribute on my test.

I wanted to try using the app.config to define my data sources so that I could make them dynamic and configure them at test execution time so that I could point my tests at different environments.

I started following this tutorial on MSDN. It shows how to define data sources in the app.config for the tests. Then I followed the guidance in this post on the MSDN forums for how configure XML data sources in the app.config. Once I did that, I set up my XML data file similarly to the following:

<?xml version="1.0" encoding="utf-8" ?>
<Rows>
<dev>
<ShouldExist>True</ShouldExist>
<ProjectNumber>1721202</ProjectNumber>
</dev>
<dev>
<ShouldExist>False</ShouldExist>
<ProjectNumber>00000</ProjectNumber>
</dev>
</Rows>

The second-level "dev" elements are the "data table" in the connection parameters for the data source. By naming these appropriately, I can now select the environment in which to run my tests as part of my automated builds (yay ALM).

Solving "System.Net.WebException: The remote server returned an error: (417) Expectation Failed" with a WCF service

I recently started getting the following error message when trying to connect to a web service we had put on an Azure VM running behind an Azure load balancer:

System.ServiceModel.ProtocolException: The remote server returned an unexpected response: (417) Expectation Failed. ---> System.Net.WebException: The remote server returned an error: (417) Expectation Failed.

It turns out the fix was to put the following element in my <configuration> :

<system.net>
<settings>
<!-- This is required when running in Azure VMs behind an Azure load balancer -->
<servicePointManager expect100Continue="true" />
</settings>
</system.net>

Solving "System.Net.WebException: The remote server returned an error: (417) Expectation Failed" with a WCF service

I recently started getting the following error message when trying to connect to a web service we had put on an Azure VM running behind an Azure load balancer:

System.ServiceModel.ProtocolException: The remote server returned an unexpected response: (417) Expectation Failed. ---> System.Net.WebException: The remote server returned an error: (417) Expectation Failed.

It turns out the fix was to put the following element in my <configuration> :

<system.net>
<settings>
<!-- This is required when running in Azure VMs behind an Azure load balancer -->
<servicePointManager expect100Continue="true" />
</settings>
</system.net>

Solving the error "We could not add the account: network_not_available: The network is down so authentication cannot proceed" when trying to sign into Visual Studio

This has been driving me nuts for years. The solution, as it turns out, is ridiculously simple: at the top right of Visual Studio, go to your signed in account => Account Settings ...

On the dialog that pops up, sign out of all accounts and close the window.

While signed out, close and restart Visual Studio.

Sign in again with your accounts. You should be good to go.

Apparently signing out and closing Visual Studio is the only way to truly clear its credential caches. Fuck.

Solving the error "We could not add the account: network_not_available: The network is down so authentication cannot proceed" when trying to sign into Visual Studio

This has been driving me nuts for years. The solution, as it turns out, is ridiculously simple: at the top right of Visual Studio, go to your signed in account => Account Settings ...

On the dialog that pops up, sign out of all accounts and close the window.

While signed out, close and restart Visual Studio.

Sign in again with your accounts. You should be good to go.

Apparently signing out and closing Visual Studio is the only way to truly clear its credential caches. Fuck.

Solving the error "We could not add the account: network_not_available: The network is down so authentication cannot proceed" when trying to sign into Visual Studio

This has been driving me nuts for years. The solution, as it turns out, is ridiculously simple: at the top right of Visual Studio, go to your signed in account => Account Settings ...

On the dialog that pops up, sign out of all accounts and close the window.

While signed out, close and restart Visual Studio.

Sign in again with your accounts. You should be good to go.

Apparently signing out and closing Visual Studio is the only way to truly clear its credential caches. Fuck.

Getting started with creating custom Build and Release tasks for VSO

You'll need to follow the steps below in order to get started:
1) Install npm for Windows if you haven't already
2) Once npm is successfully installed and available in your PATH, execute the following command to install the TFX command line package: "install -g tfx-cli"
3) Once you've installed TFX, find a folder in which you want to work to create your package, and execute a command similar to the following: "tfx build tasks create"
4) After you finish answering the questions asked by the program, you'll have a template folder for your custom build task that you can bundle up with tfx and publish to VSO.

Passing parameters from a resource group template in Azure to a WebJob

As it turns out, WebJobs retrieve their connectionStrings and appSettings from the Azure app service blade settings, same as the web application in which they're running! You can just use the built-in "connectionstrings" and "appsettings" resources underneath a Web Application in your Resource group template to populate these values for the WebJobs right from your template. This is particularly useful for things like WebJobs dashboard and storage connection strings.  Microsoft could really have done a better job of advertising this fact.

MSMQ, WCF and IIS: Getting them to play nice: The extras, Part II

Here's another catch I've found that causes issues when trying to set up a 3-party queueing system: You need to log on interactively as the user that's accessing the queues on each of the machines where it's accessing the queues! This is so that a certificate can get created for the user on those machines to be used with Active Directory authentication.

Solving "m_safeCertContext is an invalid handle."

I've recently been trying to get an application working in Azure App Service that acts as a client who calls out to another service via WCF with TransportWithMessageCredential mode for security and Certificate mode for authentication. I've been getting the following error:

m_safeCertContext is an invalid handle.

According to this blog post, this error gets thrown when the certificate isn't correctly imported or has incorrect trust (for any of many possible reasons). Some of those reasons can include incorrect passwords, but there are others as well, like what I was encountering: in Azure App Service, there's no local user signed on when your application is running. Because of that, you run afoul of a subtle issue with managing certificates: all of the constructors, by default, use the user certificate store to temporarily store the PrivateKey of any loaded X509Certificate2 objects. Therefore, on an Azure App Service application, unless you use the new X509Certificate2(certBytes, passwordString, X509KeyStorageFlags.MachineKeySet | X509KeyStorageFlags.Exportable) constructor with the MachineKeySet | Exportable flags, your certificate will not be correctly read and will SILENTLY FAIL!!

Solving 'The remote certificate is invalid according to the validation procedure' with WCF channels

This typically happens most often (when using certificates) when the certificate Common Name (CN) doesn't match the DNS host name of the server.

Solving "Binding validation failed because the binding's MsmqAuthenticationMode property is set to WindowsDomain but MSMQ is installed with Active Directory integration disabled"

I've been trying to set up remote reads from an MSMQ queue to a WCF service hosted on another machine. I seem to have all my application settings correct, but I'm being screwed over by machine-level configuration on the service machine: the service machine won't run in Active Directory mode, no matter what I do.

After searching for the problem, I found this page on John Breakwell's MSDN blog. It describes the problem: essentially there's a legacy msmq object left around when you install MSMQ Server and Active Directory Integration features together in the same transaction. Here's how you **actually** fix the problem:

1. Uninstall all of the MSMQ features.
2. Execute this PowerShell command (or one similar to it) to actually delete the Active Directory object described in the article (which doesn't go into nearly enough detail on this point):  get-adobject -filter “name -eq ‘msmq'” | Where { $_.DistinguishedName -eq ‘CN=msmq,CN=MyAffectedServerNameHere,OU=Web Servers,OU=Member Servers,DC=MyDomainNameHere,DC=Network,DC=ads’} | Remove-ADObject
3. Reinstall **just** MSMQ server, then reboot your machine.
4. Reinstall **just** MSMQ active directory integration, then reboot your machine.

You should now be good to go.