Powershell command as scheduled task

Here’s the syntax to use a PowerShell command in Task Schedule action, rather than a script:

Program/script:

powershell.exe

Add Arguments:

-noninteractive -executionpolicy bypass -command &{Checkpoint-VM -Name pxetest -SnapshotName 2018-06-23-PreMaintenance}

 

The key here is the ampersand before the command – when I was missing that it would not run.

 

 

SharePoint library column missing

I’ve been working on migrating documents between document libraries in a SharePoint site, and have randomly struggled with an odd issue.

In the new destination library, I’ve configured a managed metadata column based on a term store, and made it mandatory. This column does not exist on the source library.

For the majority of my documents this has been working well – after moving or copying the document I set the column value with the quick-edit info pane. However, some of the documents have a blank value rather than showing “Required Information”:

click for bigger

When I view the properties of the document on the quick-edit pane, the column doesn’t appear at all!

The root cause is that these problem documents carried over their Content Type with them into the new library, and this content type does not have the managed metadata column added to it. However, it isn’t immediately clear this is what happened because the default setting on this library is to not manage Content Types individually.

To fix this, I went into the advanced library settings, and chose Yes for “Allow management of content types”:

Once I did this, the extra content type appeared in the settings page:

click for bigger

Now when I go back to my document and open the quick-edit pane, there is a new option to select Content Type, and I can set it back to the default:

This then updates the list and puts a “Required Information” block in that column, and allows me to fill it in.

 

ASR Deployment Planner throughput test failure

I’m preparing an environment for the Azure Site Recovery Deployment Planner tool, and ran into a problem with one of the tests. With this tool, you can run a few different tests independently:

  • GetVMList – generate a list of VMs from specified hosts
  • StartProfiling – run a profile job on the generated list of VMs, over a specified period of time
  • GenerateReport – generate output report of results based on dataset collected in the “StartProfiling” job
  • GetThroughput – run an upload test to an Azure Storage Account to get measurements of viable throughput for your environment (optionally done in the “StartProfiling” job too)

When I ran the StartProfiling job, I encountered a bunch of errors at the end which indicated it was related to the throughput test. So then I independently ran that, and encountered the following errors:

Output not in a definite format
click for bigger

UploadTest.exe has stopped working

 

There isn’t any other mentions online of this error that I could find, but I went back to the tool requirements and realized that I had missed a prerequisite.

Once I installed the Microsoft Visual C++ Redistributable for Visual Studio 2012 as identified from the ASR doc, the throughput test succeeded without further errors.

Install Windows Feature from Source

Here’s the syntax to use when trying to use Install-WindowsFeature cmdlet with source as ISO mounted as DVD:

Install-WindowsFeature -Name "Web-App-Dev" -source wim:f:\sources\install.wim:4

Interestingly, when I tried to do this with the feature “Web-Net-Ext” for the .net 3.5 extensibility, it failed with a download error.

Even trying to install .net 3.5 through Install-WindowsFeature or the Server Manager failed with a similar error.

I had to install it through DISM, and then the rest of the command worked:

Dism /online /enable-feature /featurename:NetFX3 /All /Source:F:\sources\sxs

 

Azure Site Recovery and Backups

I’m working on a specific test case of Azure Site Recovery and came across an error, which identified a gap in my knowledge of ASR and Hyper-V Replica.

I have ASR configured to replicate a group of VMs at 5 minute intervals. My initial replication policy for this proof-of-concept was configured to hold recovery points for 2 hours, with app-consistent snapshots every 1 hour.

In practice, what I have seen for potential select-able recovery points is one every 5 minutes going back to the latest application-consistent recovery point, and then any additional app-consistent recovery points within the retention time set (2 hours):

Because the underlying mechanism is Hyper-V Replica, this corresponds to the options for Recovery Points visible in Hyper-V Manager:

Hyper-V will perform the .HRL file replication to Azure every 5 minutes as configured, but it will also utilize the Hyper-V integration components to trigger in-guest VSS for the application-aware snapshot at 1 hour intervals. This means the RPO in general is up to 5 minutes, but for application-aware RPO it is 1 hour.

 

In addition to replication, I am backing up a VM with Quest Rapid Recovery. The test was to ensure that both protection methods (Disaster Recovery and Backup) do not conflict with each other. Rapid Recovery is running an incremental snapshot every 20 minutes, and on about 40% of them the following events are received in the Application Log for the VSS service:

Volume Shadow Copy Service error: The I/O writes cannot be flushed during the shadow copy creation period

Volume Shadow Copy Service error: Unexpected error DeviceIoControl(\\?\Volume{a9dca4cb). hr = 0x80070016, The device does not recognize the command.

 

Quest has a KB article about this issue, which says to disable the Hyper-V integration component for backup in order to avoid a timing conflict when the host uses the Volume Shadow Copy requestor service. The problem is, disabling this prevents ASR from getting an application-aware snapshot of the virtual machine, which it will begin to throw warnings about after a few missed intervals:

These problems make sense though – for every hourly attempt of Hyper-V to take an application-aware snapshot using VSS, Rapid Recovery finds that writer in use and times-out waiting for it. There isn’t a way to configure when in an hour Hyper-V takes the snapshot, but I’ve begun tweaking my Rapid Recovery schedule to not occur on rounded intervals like :00 or :10, but rather :03 or :23 in an attempt to avoid conflicts with the VSS timing. So far this hasn’t been as effective as I’d hoped.

The other alternative is to disable application-aware snapshots if they’re not needed. If it is just flat files or an application that doesn’t natively tie into VSS, the best you can expect is a crash-consistent snapshot and you should configure your ASR replication policy accordingly, by setting that value to 0. In this manner you can still retain multiple hours of recovery points, they’ll just ALL be crash-consistent.