Johnny BizTalk

The Azure PowerShell session has not been properly initialized.

jftl6y_007 — Thu, 06 Jul 2017 15:41:58 GMT

I recently tried to update my Azure PowerShell version and noticed that even though I had run the "Install-Module AzureRM -force -allowclobber" command, which SHOULD overwrite your current version, I was still stuck on version 3.8.0 instead of the 4.1.0 version (latest) I was trying to install. Doing a "Get-Module -Name Azure" showed BOTH versions installed. I played with a few things, including forcibly uninstalling some of the modules under the "Azure" module, and eventually got what appeared to be a correct version running. However, when I tried to run a simple command (e.g. Get-AzureRMResourceGroup) I would receive the following error: "Get-AzureRMResouceGroup: The Azure PowerShell session has not been properly initialized. Please import the module and try again." After re-running the install a few times, I had an inkling that I had "something" corrupt/old that was causing these issues. I end up installing a lot of SDKs, tools, add-ins, both pre-release and RTM on my machine and something somewhere was unhappy and getting hung up. To fix this, I did the following:

get-module azure* -list |uninstall-module
1. This will uninstall all modules starting with azure*. You probably will get some red on this as there are a few order of operation dependencies. Just roll on.
In control panel, uninstall all of the Azure related widgets which have been installed
Reboot
Repeat Step 1 to remove any final modules which may exist (in my case AzureRM.Profile).
Install Azure PowerShell via your favorite means (WebPI, PowerShell, MSI).

After I'd 'cleaned' my installs, no more issues. HTH someone

Little gotcha in Docker for Windows

jftl6y_007 — Wed, 29 Mar 2017 12:58:39 GMT

I am writing a small ASP.NET Core Web Application and decided to add Docker support. However, even though this was a vanilla application built from the Visual Studio project template, I kept getting the following error trying to run this: "Can not find the container with the name starting with dockercompose1234567890" Docker appeared healthy and my other containers were running fine, but for some reason it wasn't able to fire up the container it created dynamically to run my app. So I went out to PowerShell and tried a "docker ps -al" and realized the container did not exist. I ran through the setup guide here and looked at the requirement to share a drive (e.g. the C drive). I knew I'd already done this, but as Docker has been updated several times, I thought I'd verify. The setting was still checked to share the drive, but when I hit the "Apply" button it prompted me for my current credentials. And then it dawned on me that I'd probably changed my password 10 times since I originally configured Docker on this machine, so it was trying to use old cached creds to access the file system. I'm surprised this hadn't reared its head before in some other way, but the morale of the story is, when you change your Windows password, make sure you remember to update it in Docker as well. HTH

Moving databases to new storage within an Availability Group

jftl6y_007 — Mon, 06 Mar 2017 20:06:15 GMT

I had a customer come to me for help in adding storage for their SQL servers which were supporting their SharePoint farm. Their SQL architecture consisted of three (3) SQL servers configured in an AlwaysOn Availability group. One server was configured as the primary replica for Search, one as the primary replica for Content, and the third server as the primary replica for "Other." Each of the servers then served as a secondary replica for its sister servers. For the purposes of this article I will refer to these servers as Server1(Search), Server2(Content) and Server3(Other). The customer had a constraint imposed by their virtualization layer that no disk could be larger than 2 TB, and the size of their content databases was getting near to the limit. The solution we arrived upon was to simply add another disk and move some of the content databases to spread the workload out onto the new storage. As there were almost 200 individual content databases (and because I am inherently lazy) I wasn't keen on doing an detach/move/attach for each one. Starting with this article, I developed another procedure which was much faster and only involved a couple of Availability Group failovers in terms of downtime. In short, the process is to run a series of "Alter Database...Modify File" statements which in effect moves the pointer to where SQL expects the file to be, stop SQL, move the .mdf database files, and then start SQL again. In order to make things as easy as possible, I wrote a T-SQL script which creates the "Alter Database...Modify File" statements automatically based upon where things currently reside and where they should reside in the future, as well as the copy and delete (cleanup) scripts to run on the file system. All you have to do is add the names of your databases and the new storage location. Then it's simply a matter of shuffling things around between the servers. That process is as such (and assumes you've taken a recent back up of everything):

Disable read-only access on each secondary replica
On each server, run the script (below) which will create the "Alter Database...Modify File" statements as T-SQL, as well as the copy and delete scripts, which can be run in a command or PowerShell prompt.
1. Suggest that you save the copy and delete statements as command files (.cmd) on each of the servers.
On each secondary (i.e. Server1(Search) and Server3(Other)), run the "Alter Database...Modify File" statements. This will move the pointers for the data files.
Server1(Search) and Server3(Other) are currently primary replicas for the Search and Other Availability Groups. Fail these over to Server2(Content) so Server2(Content) is now the primary replica for all three AGs.
Stop the SQL Services on Server1(Search) and Server3(Other).
Run the Copy statements as an elevated user on Server1(Search) and Server3(Other). This will copy the database files to their new location.
Start the SQL Services on Server1(Search) and Server3(Other).
In SSMS, verify that the moved databases are showing healthy and are participating in replication after they recover.
Move the Search and Other Availability Groups back to Server1(Search) and Server3(Other), respectively, so they are again the primaries for their Availability Group.
Move the Content Availability Group to make the Server1(Search) server the primary replica.
Run the "Alter Database...Modify File" statements on Server2(Content). This will move the pointers for the data files.
Stop the SQL Services on Server2(Content)
Run the Copy statements as an elevated user on Server2(Content). This will copy the database files to their new location.
Start the SQL Services on Server2(Content).
In SSMS, verify that the moved databases are showing healthy and are participating in replication after they recover.
Move the Content Availability Group back to Server2(Content).
Final step (when all databases are healthy and online): Run the "Delete" scripts on all three servers to clean up the old database files.

With that set of procedures and a couple of interruptions of the AG listeners, we are able to move the databases around with little to no apparent disruption to users. This is important because, as the size of the database we are moving gets larger, the copy time increases as well. This process avoids this problem as we're always working against a secondary replica, not the primary. Here's the script:


/*Update the @newLocation variable for your actual new data file location*/
/*Update the values to load into the @sourceDBs table to reflect your actual database names*/
DECLARE @sourceDBs TABLE (name nvarchar(500))
DECLARE @newLocation nvarchar(500) = 's:\sqldata\'

MERGE INTO @sourceDBs as target
using (VALUES ('Content_DB1'),
('Content_DB2')) as source (name)
on target.name = Source.name
when not matched by target then insert (name) values (name);

;with CTE as (
select d.name as [DB_Name],
f.name as [File],
f.filename as [FilePath],
reverse(left(reverse(f.filename),(charindex('\',reverse(f.filename),0))-1)) as [FileName]

from sysaltfiles f
inner join sysdatabases d
on (f.dbid = d.dbid)
inner join @sourceDBs sdb on sdb.name = f.name
)
select 'Alter Database [' + [DB_Name] + '] modify file ( name = [' + [File] + '], filename = N''' + @newLocation + ''');' as alterDBScript, 'xcopy "' + [FilePath] + '" ' + @newLocation + ' /Y' as CopyCommand, 'powershell rm "' + [FilePath] + '"' as DeleteCommand from CTE

Creating a Hyper-V host with Nano Server – Part 3

jftl6y_007 — Sat, 24 Dec 2016 22:18:09 GMT

In Part 2, I covered initially connecting via PSRemoting and domain joining the Nano Server. In this part I'll cover finishing the Nano Server installation as a Hyper-V host managed by System Center Virtual Machine Manager 2016. And for that, I'll take an aside into updating Nano Server packages. In Part 1 I mentioned making sure that you included the SCVMM packages for Nano Server in the initial image. There is a provision for adding these and other (e.g. IIS) packages on a running Nano Server install, either via DISM (explanation here under "Install the VMM packages offline on an existing Nano Server VHD(X)") or via OneGet (explanation here). I found the OneGet method more intuitive and consistent with everything PowerShell, but your preferences may be different. However, I kept getting failures trying to install the SCVMM packages, via both the DISM and OneGet methods. The error was:

install-package : Add-WindowsPackage failed. Error code = 0x800f0922
+ CategoryInfo : InvalidOperation: (System.String[]:String) [Install-Package], Exception
+ FullyQualifiedErrorId : FailedToInstall,Install-PackageHelper,Microsoft.PowerShell.PackageManagement.Cmdlets.InstallPackage

At the end of the article on github, I found that installing the SCVMM package has a known issue. I tried the workarounds but ultimately I think it was due to a missing dependency. I played around some and "something happened" that looked successful, but when the Nano Server rebooted it came up in a corrupt state (something about the digital signature changing). At any rate, as reimaging is so fast, I punted and just made a new Nano Server image with the correct packages. Anyhow, enough about package management in Nano Server, though I find the whole process for managing these pretty neat and am looking forward to how this changes.

Adding the Nano Server to SCVMM 2016

At this point, all that was left was adding the Nano Server to SCVMM. I added the SCVMM runas account to the Administrators group on the Nano Server. I opened up my SCVMM console, right-clicked the "All Hosts" group and selected "Add Hyper-V Hosts and Clusters" and ran through the wizard to add the Nano Server. At this point, it's pretty much a standard Hyper-V host, albeit one that runs lightning fast and takes up a minimal footprint. I added the virtual switch and it was off to the races to deploy some VMs. Hopefully this little series of articles distilled down several disparate articles and provides a complete end-end demonstration of Nano Server and SCVMM 2016.

Creating a Hyper-V host with Nano Server – Part 2

jftl6y_007 — Sat, 24 Dec 2016 21:31:51 GMT

In Part 1 I went over how to create the Nano Server image and configure the physical computer to boot to the VHD. In this part I'll explain how to access the computer and get it configured, to include domain join.

Remoting to Nano Server

Unlike previous Server Core installations, Nano Server is truly headless in that it has no local UI for administration. Having said that there is an emergency recovery console you can log in to if you want to configure network, firewall, etc. Unless you have included network configuration information when you created your image (get-help new-NanoServerImage) Nano Server will attempt to use DHCP. At this point you may want to use the console to set a static IP, or scan for the address dynamically assigned to the Nano Server. If you create a static IP, make sure you add DNS information with the Set-DNSClientServerAddress cmdlet. Once you know or have set the IP address to your Nano Server, you can remote to it. However, for security reasons, PowerShell will not accept an IP address for the ComputerName parameter in Enter-PSSession unless it's placed in Trusted Hosts. That command is: Set-Item WSMan:\localhost\Client\TrustedHosts "192.168.1.93" At this point you may remote to your Nano Server with a standard Enter-PSSession command, as follows: Enter-PSSession -computerName 192.168.1.93 -cred "Ragestroke\administrator"

Domain Joining the Nano Server

While you can configure and administer Nano Server with PowerShell, some features you may be used to (e.g. get-windowsFeature, add-computer, etc.) are not available. To domain join the computer, you must use the DJoin.exe utility to create an offline domain file. On a domain joined computer, execute the following command from an elevated command prompt. djoin /provision /domain ragestroke.com /machine RageNanoHV01 /savefile domainJoin.djoin *Note: If reusing the machine name, specify the /reuse switch. Next, use a standard net use command to connect to your Nano Server and copy the djoin file.

net use z: \\192.168.1.93\c$
copy .\domainjoin.djoin z:

Finally, via your remote PowerShell session on your Nano Server, use the djoin tool to request an offline domain join:

djoin /requestodj /loadfile .\domainJoin.djoin /windowspath c:\windows /localos
restart-computer

At this point the computer is domain joined and ready for work. I'll conclude this series in Part 3.

Creating a Hyper-V host with Nano Server - Part 1

jftl6y_007 — Sat, 24 Dec 2016 20:04:56 GMT

Recently I decided to re-build my home lab cleanly with Windows Server 2016 and System Center 2016. Amongst my collection of disused components includes an older laptop workstation which has decent specifications and would make a good Hyper-V host. So I decided to try my hand at making this machine a Nano Server and manage it via SCVMM. There are many blogs out in the interwebs that describe this, but I thought I'd document my journey as well. In this post I'll outline getting the Nano Server VHD image created and getting the physical machine setup to boot to the VHD.

Create the Nano Server image

The first step of this process is to create the Nano Server image. There are a number of good blog posts that tell you how to do this, but I'll give you the short version.

Mount the Windows Server 2016 media
Under the root of the Windows Server 2016 media, there is a folder called Nano Server. Under this is a folder called NanoServerImageGenerator. Copy this to your local drive.
Open a PowerShell session as an administrator and navigate to the NanoServerImageGenerator folder which was copied locally.
Enter the following command, changing the parameters to suit your needs

new-nanoserverimage -computerName RageNanoHV01 -edition Standard -deploymentType host -mediaPath "e:\" -basePath .\Base -TargetPath .\NanoServerPhysical\NanoServer1.vhd -oemDrivers -compute -clustering -package Microsoft-NanoServer-SCVMM-Package,Microsoft-NanoServer-SCVMM-Compute-Package

A couple of notes about the command above - you can read the documentation for the new-NanoServerImage cmdlet yourself, but note the -deploymentType parameter is "host" as opposed to "guest" as it would be for a virtualized Nano Server image. The other piece is that I've included the packages supporting SCVMM explicitly when creating the VHD. Theoretically you can add these packages after the server is deployed (more on that later) but I ran into a number of issues with this and eventually corrupted my image. Otherwise, replace the -computerName, -mediaPath (location of your Windows Server 2016 media) and -targetPath values with what makes sense for your environment and the script will create a VHD with your Nano Server image.

Create the bootable drive

The next step is to create bootable media. Again, there a number of blogs on how to create a VHD and boot a physical computer to it, but here's the short steps.

Find a trusty USB you don't mind erasing
Download and install the latest Windows Assessment and Deployment Kit (ADK)
Open an administrative command prompt and type the following command

makeWinPEMedia /ufd c:\temp\winpe_amd64 f:

Change f: to wherever your USB is located. Accept the prompt asking if you want to erase your media and, voila, you have a bootable USB
Copy the Nano Server image VHD you created in the steps above to the USB drive

Configure Boot to VHD (Native Boot)

I'll summarize these steps as well, but lifted from Boot to VHD (Native Boot): Add a Virtual Hard Disk to the Boot Menu

Plug your USB into the physical computer and reboot
Bring up your boot menu and boot to the USB device
The Windows PE environment will launch
Execute the following diskpart commands


diskpart
select disk 0
clean
create partition primary size=300
format quick fs=ntfs
assign letter=s
active
create partition primary
format quick fs=ntfs
assign letter=c
exit
copy F:\NanoServer1.vhd c:
diskpart
select vdisk file=c:\NanoServer1.vhd
attach vdisk
list volume
select volume (number where the vhd is mounted)
assign letter=v
exit
cd v:\windows\system32
bcdboot v:\windows
diskpart
select vdisk file=c:\NanoServer1.vhd
detach vdisk
exit

And that's it. When you restart the computer it will now launch to the Nano Server VHD image you copied to the physical machine. Note that the location of your USB bootable media may be different, but you can see this in diskpart. Part II will cover configuring the headless Nano Server via PowerShell remoting and getting it on the domain and ready to do work.

Updating multiple SQL instances simultaneously

jftl6y_007 — Thu, 28 Apr 2016 19:56:50 GMT

A customer I was working with has undergone a lot of growth recently, and to support their development efforts has deployed a LOT of dev/test environments. As often happens with rapid growth and expansion, these environments were in varying states depending on the care and feeding they'd been receiving, and we were helping them get a handle on these environments, standardizing their management and configuration with a variety of tools and best practices. One piece that sorely needed to be addressed was getting all of the SQL instances (which included databases instances as well as SSRS and SSIS servers) up to a common patch level. As they had so many servers to patch, they asked if I could write something to help (they do have patch management software, but didn't use it for SQL service packs of CUs). I went ahead and wrote a small PowerShell snip which I share here which uses the ForEach -parallel workflow which takes a list of servers and, on each one simultaneously runs the service pack. It's not really very interesting, although I did discover that when you connect to a remote share within the Invoke-Command window, the identity comes across as anonymous, so injecting the credentials with a PSDrive fixed that. Anyhow, there's a lot more you could do with this, and you could extend the pattern for running about any executable. You'd also likely not want to do this in a production environment, especially with clustered SQL instances, as there you'd want to deliberately patch the passive node(s), roll the instance and patch the remaining node, instead of the "Blindly apply patch restart" school of updating. But it did do a great job of simultaneously (and quickly I might add) get a few dozen SQL instances up to a common patch level. Enjoy.


$targetServers = @("Server1","Server2","Server3","Server4")
$patchSource = "\\fileshare1\SQLMedia"
$patchFile = "\SQLServer2012SP3-KB3072779-x64-ENU.exe"
workflow ApplyUpdates
{
param (
$targetServers,
$patchSource,
$patchFile,
$cred)
foreach -parallel ($server in $targetServers)
{
$defaultDestPath = "\\$server\c$\temp"
$defaultDestFull = $defaultDestPath + $patchFile
$defaultSourceFull = $patchSource + $patchFile
InlineScript
{
Invoke-Command -ComputerName $using:server -ArgumentList $using:Cred, $using:patchSource, $using:patchFile -ScriptBlock {`
param (
$cred,
$patchSource,
$patchFile)
New-PSDrive -name PatchDrive -Root $patchSource -PSProvider FileSystem -Credential $cred
$installSource = "PatchDrive:\" + $patchFile
$arguments =@()
$arguments += "/quiet"
$arguments += "/allinstances"
$arguments += "/IAcceptSQLServerLicenseTerms"
Start-Process $installSource -wait -ArgumentList $arguments -verb runas
Restart-Computer -Force
}
}
}
}
$cred = Get-Credential
ApplyUpdates $targetServers $patchSource $patchFile $cred

Yet another cause for "Enterprise Single Sign-On Server: Unspecified error"

jftl6y_007 — Tue, 13 Jan 2015 13:24:09 GMT

My customer's BizTalk environment uses a 2-node failover cluster to host the SQL instances where the BizTalk databases live. We also clustered Enterprise SSO on this failover cluster. Recently there was a catastrophic issue with the NAS device where the VM storage lived, and one of the nodes of this cluster didn't come back cleanly when the NAS issue was resolved (essentially the cluster service refused to start). In that this was about the only virtual machine to come up in a bad state (out of 60 some) I counted myself lucky.

As I had provisioned this in SCVMM with a service template, it was a simple matter to scale out my database tier by one and replace the bad node and in short order I had SQL installed and configured on the new node. The final step was to install and reconfigure SSO on the new node, including restoring the master secret so SSO would fail over cleanly. And here's where the fun started.

When I ran the install script to install SSO on the new node, it promptly through an error: The following platform Components failed to install and will need to be manually installed before setup can be processed: Enterprise Single sign on server: Unspecified Error

I'd seen this before and a quick mental scan reminded me that the clustered DTC resource needs to be on the local node while installing SSO. Problem: the clustered SSO resource is ALSO in the DTC resource and will not fail over to the new node until SSO is installed and configured there. Chicken, meet egg.

The fix at the end of the day was to remove the SSO resource's dependency on DTC and move it to another resource group temporarily, then move DTC over to the new node. Then it allowed me to finish my install. Then I moved DTC BACK to the original node and moved SSO back to the DTC resource (and re-adding the dependencies I'd removed) so I could configure the resource. Once all of that was done, I was able to run my script to restore the master secret and the new node was fully configured for duty.

Activating a Windows 2012 R2 Server offline

jftl6y_007 — Wed, 15 Oct 2014 07:56:18 GMT

If you're trying to activate a server which has no internet connectivity or access to a KMS server, your options for activating Windows are narrowed to calling the automated phone service. In previous versions of Windows, it would prompt you to enter a product key, then ask if you would like to activate over the internet. If you declined, you'd be given the phone option.

In Windows Server 2012 R2 the behavior is different, in that when you activate the product key, you are simply told that it is an invalid key. In truth, the server is trying to validate the key over the internet, which of course doesn't work if your server doesn't have a path out.

The key (ahem) is a couple of command lines:

slmgr -ipk XXXXX-XXXXX-XXXXX-XXXXX-XXXXX (where "X" is your product key)

slui 4

This will bring up the UI, similar to previous Windows versions, that will walk you through phone activation.

Cannot bring SQL resource online after installation

jftl6y_007 — Sat, 11 Oct 2014 15:59:05 GMT

I'm going through what feels like iteration 14,354 of the process to migrate my customer to a completely new platform, which involves moving from physical to virtual resources and leaping forward 3-4 product versions for just about every product on which the customer's solution runs, which includes a generous helping of SQL Server.

I'm building several clustered SQL instances and to save time (and sanity) am using a scripted approach to install SQL. Everything was going along swimmingly until I hit a wall on one failover cluster with two SQL instances. With both instances, the SQL installer would run almost to completion until it would get to the point where it tried to online the SQL cluster resource, and it would just hang for several minutes and then fail. The error in the log was:

“The cluster resource 'SQL Server (MyInstance1)' could not be brought online. Error: There was a failure to call cluster code from a provider. Exception message: Generic failure . Status code: 5023. Description: The group or resource is not in the correct state to perform the requested operation.”

As I'd installed literally a dozen other SQL instances using my scripts before, I was perplexed as to why this cluster was giving me issues. Bing'ing around didn't give me much in the way of results (and many of the hits on that error were red herrings), so I went exploring the Event Logs. One thing that caught my eye was that in the System Event Log I had an error for the following:

Cluster network name resource 'SQL Network Name (MySqlNetworkName)' failed registration of one or more associated DNS name(s) for the following reason:
DNS operation refused.

Now remember I said it felt like iteration 14,354 of this process? That's because I've installed many of these SQL instances, using the same names, in slightly different configurations, as part of earlier efforts. When I checked DNS, lo and behold there were stale DNS records of my SQL network name resources. Once I deleted these, I was off and running.

HTH someone in the future - this was NOT a fun one to figure out.