There are two new features introduced in Windows Server 2012 related to iSCSI: iSCSI Target Server and Storage Provider. My previous blog post discussed the iSCSI Target Server in depth, this blog post will focus on the providers.

Introduction

There are two providers included in the storage provider feature:

· iSCSI Target VDS hardware provider: Enables you to manage iSCSI virtual disks using older applications that require a Virtual Disk Service (VDS) hardware provider, such as the Diskraid command.

· iSCSI Target VSS hardware provider: Enables applications, such as a backup application that are connected to an iSCSI target to create volume shadow copies of data on iSCSI virtual disks.

Note: VDS and VSS utilize different provider models. iSCSI Target storage providers follows the hardware provider model, hence the naming convention.

Overview

VSS hardware provider

The VSS (Volume Shadow Copy Service) is a framework that allows a volume backup to be performed while the application continues with IOs. VSS coordinates among the backup application (requester), application (such as SQL) (writers) and the storage system (provider) to complete the application consistent snapshot. A detailed concept of VSS is explained here.

The iSCSI Target VSS hardware provider communicates with the iSCSI Target server during the VSS snapshot process; thus ensuring the snapshot to be application consistent. The diagram below illustrates the relationship between the VSS components.

One feature added in Windows Server 2012 for the iSCSI Target VSS hardware provider is the support of auto-recovery. Auto-recovery allows the VSS writer to modify the snapshot in the post-snapshot phase. This requires the provider to support write operation in the post-snapshot window, before making the snapshot read-only. This feature is also required by the Hyper-V host writer. With auto-recovery support, you can now run Hyper-V host backup against iSCSI Target Storage.

VDS hardware provider

The VDS (Virtual Disk Service) manages a wide range of storage configuration. In the context with iSCSI Target, it allows storage management applications to manage iSCSI Target Server. For the service architecture, this page provides more the details, along with the roles of the providers. The diagram below illustrates the relationships between the VDS components.

As you may have read in the VDS overview for Windows Server 2012, the VDS service is superseded by the Storage Management APIs, the VDS hardware provider is included for backward compatibility. If you have storage management applications requires VDS, you will be able to continue to run the application. For new application development however, it is recommended to use Windows Storage Management APIs. Note, iSCSI Target in Server 2012 only support VDS.

To use the VDS hardware provider to manage iSCSI Target Server, you must install the VDS provider on the storage management server. You also need to configure the provider so that, it knows which iSCSI Target Server to manage. To do so, you can use the powershell cmdlet below to add the server:

PS C:\> $PrvdSubsystemPath = New-Object System.Management.ManagementPath("root\wmi:WT_iSCSIStorageSubsystem")

PS C:\> $PrvdSubsystemClass = New-Object System.Management.ManagementClass($PrvdSubsystemPath)

PS C:\> $PrvdSubsystemClass.AddStorageSubsystem("<remote-machine>")

Installation

The iSCSI Target storage providers are typically installed on the application server, as illustrated by the diagram below:

Windows Server 2012

To install the storage providers on Windows Server 2012, use Server Manager, you can run Add roles and features wizard, and then select the iSCSI Target Storage Provider (VDS/VSS hardware provider)

Alternatively, you can also enable it from the cmdlet

PS C:\> Add-WindowsFeature iSCSITarget-VSS-VDS

Down Level Operating System support

As you can see from the diagram above, the iSCSI storage providers are typically installed on a different server from the server running iSCSI Target Server. If iSCSI Target Server is running on Windows Server 2012, and the application server is running a previously-released Windows operating system, you will need to download and install the down-level storage providers. The download package is available on the Download Center at http://www.microsoft.com/en-us/download/details.aspx?id=34759

There are three files to choose from:

· 64 bit package that runs on Windows Server 2008 (Windows6.0-KB2652137-x64.msu)

· 32 bit package that runs on Windows Server 2008 (Windows6.0-KB2652137-x86.msu)

· 64 bit package that runs on Windows Server 2008 R2 (Windows6.1-KB2652137-x64.msu)

If you have any application server running on Windows Server 2008 or R2, connected to Server 2012 iSCSI Target, you will need to download the appropriate package, and install it on the application server, and configure the credentials as described in the Credential configuration section. You can simply follow the installation wizard.

Storage Provider support matrix

To complete the picture of storage provider and iSCSI Target version support, see the table below:

iSCSI Target 3.2 <-> installed on Windows Storage Server 2008

iSCSI Target 3.3 <-> installed on Windows Storage Server 2008 R2 and Windows Server 2008 R2

iSCSI Target (build-in) <-> included with Windows Server 2012

Note:

1: Storage provider 3.3 on Server 2012 can manage iSCSI Target 3.2. This has been tested.

2: The Windows Server 2012 down-level storage provider can be downloaded from: : http://www.microsoft.com/en-us/download/details.aspx?id=34759

Credential configuration

If you have used the storage providers prior to the Windows Server 2012 release, there are a few differences in this release to consider:

1. The interface between the storage providers and the iSCSI Target service has changed from private DCOM to WMI, therefore the storage providers shipped previously cannot connect to iSCSI Target Server in Server 2012. See the support matrix to check the version of the storage provider you may need.

2. The storage providers require credential configuration after being enabled.

The storage providers must be configured to run with the administrative credentials of the iSCSI Target Server computer, otherwise, you will run into “Unexpected Provider” error (0x8004230F) when taking any snapshot. Along with the error, you will also find the following error message in the Windows Event eventlog:

Volume Shadow Copy Service error: Error creating the Shadow Copy Provider COM class with CLSID {463948d2-035d-4d1d-9bfc-473fece07dab} [0x80070005, Access is denied.].

Operation:

   Creating instance of hardware provider

   Obtain a callable interface for this provider

   List interfaces for all providers supporting this context

   Query Shadow Copies

Context:

   Provider ID: {3f900f90-00e9-440e-873a-96ca5eb079e5}

   Provider ID: {3f900f90-00e9-440e-873a-96ca5eb079e5}

   Class ID: {463948d2-035d-4d1d-9bfc-473fece07dab}

   Snapshot Context: -1

   Snapshot Context: -1

   Execution Context: Coordinator

What credential to use?

For the storage providers to remotely communicate with the iSCSI Target service, they require the local Administrator’s permission of the iSCSI Target Server computer. This may also be a domain user added to the local admin’s group on the iSCSI Target Server.

To find the account with local Administrator’s permission, you can open the computer management, and click on the Administrator’s group:

For non-domain-joined servers, use a mirrored local account, i.e. create a local account with the same user name and password on both the iSCSI Target Server and the application server. Make sure the account is in the Administrator’s group on both servers.

UI Configuration (Dcom Config)

You can also use DCOM Config to configure the credentials as follows:

1. Open Component Services, open Computers, open My Computer and then open DCOM Config.

2. Locate 'WTVdsProv' and configure credentials as appropriate

3. Locate 'WTSnapshotProvider and configure credentials as appropriate

Take the WTSnapshotProvider for example:

1. Locate the provider under DCOM Config container

2. Right click on the provider, and click Properties

3. Click the Identity tab, select the This user option, then specify an account which has the iSCSI Target Server local Administrator’s permission

Cmdlet Configuration

As an alternative, you can also use powershell cmdlet to configure the credentials:

PS C:\> $PsCred = Get-Credential

PS C:\> $PrvdIdentityPath = New-Object System.Management.ManagementPath("root\wmi:WT_iSCSIStorageProviderIdentity")

PS C:\> $PrvdIdentityClass = New-Object System.Management.ManagementClass($PrvdIdentityPath)

PS C:\> $PrvdIdentityClass.SetProviderIdentity("{88155B26-CE61-42FB-AF31-E024897ADEBF}",$PsCred.UserName,$PsCred.GetNetworkCredential().Password)

PS C:\> $PrvdIdentityClass.SetProviderIdentity("{9D884A48-0FB0-4833-AB70-A19405D58616}",$PsCred.UserName,$PsCred.GetNetworkCredential().Password)

Credential verification

After you have configured the credentials, to verify, you can try to take a snapshot using diskshadow.exe.

Open a commandline prompt, and type diskshadow

Follow the prompt and type

Add volume c:

Create

If the credential is not configured correctly, it will show the following error:

Note: Remember to change the credential if the password has changed on the iSCSI Target Server for the specified account.

Conclusion

I hope this helps you get started using iSCSI Target in Windows Server 2012, or make a smoother transition from the previous user experience. If you have questions not covered, please raise it in the comments, so I can address it with upcoming postings.