How To Start Check File Server Vss Agent Service Server 2016

Article
08/31/2016
12 minutes to read

Applies To: Windows Server 2012

In Windows Server 2012, a new feature is introduced called VSS for SMB File Shares, which allows VSS-aware backup applications to create a book shadow re-create of VSS-enlightened server applications that shop data on remote SMB 3.0 file shares. This guide provides information on how to perform backups of server applications using this feature, and therefore, protect your data.

In this certificate

VSS for SMB File Shares: overview
Requirements and supported configurations
Deployment scenarios
Pace 1: Install File Server VSS Agent Service
Step two: Add a user to the Fill-in Operators local grouping on the file server
Stride iii: Perform a shadow copy

Note

This topic includes sample Windows PowerShell cmdlets that yous can employ to automate some of the procedures described. For more information, see Using Cmdlets.

VSS for SMB File Shares is an extension to the existing VSS infrastructure and consists of iv parts:

File Share Shadow Copy Provider (fssprov.dll). This is a new VSS provider on the server running the VSS-aware awarding. It manages shadow copies on remote Universal Naming Convention (UNC) paths where the application stores its data files, and and then relays the shadow re-create request to the File Share Shadow Copy Agents. Enhancements to the VSS infrastructure to support the File Share Shadow Copy Provider include updates to the API.
File Share Shadow Re-create Amanuensis (fssagent.dll). This is a new VSS requester on the file server hosting the SMB 3.0 file shares (using an UNC path) that store the application'southward information files. It manages mappings between file shares and volumes, and also interacts with the file server's VSS infrastructure to perform shadow copies of the volumes that backup the SMB 3.0 file shares (where the VSS-aware applications stores their information).
File Server Remote VSS Protocol (MSFSRVP). The File Share Shadow Re-create Provider and the File Share Shadow Re-create Agent employ this new RPC-based protocol to coordinate shadow copy requests of data stored on SMB file shares.

Requirements and supported configurations

The requirements for using VSS for SMB File Shares are listed below.

The awarding server and file server must be running Windows Server 2012.
The application server and file server must be joined to the aforementioned Active Directory domain.
The File Server VSS Agent Service role service must be installed on the file server.
The File Share Shadow Copy agent must run in a security environment that has backup operators or administrator privileges on both the awarding server and file server.
The File Share Shadow Copy agent and the awarding must run in a security surround that has no less than read-merely permission on the file share data that volition be backed up.

Annotation

VSS for SMB File Shares likewise works with third-party Network Attached Storage (NAS) appliances or other similar solutions. These appliances or solutions must support SMB 3.0 and File Server Remote VSS Protocols.

VSS for SMB File Shares supports the following configurations:

An application server configured every bit a single server or in a failover cluster.
A file server configured as a single server or in a failover cluster with continuously available or calibration-out file shares.
File shares with a single DFS Namespaces link target.

VSS for SMB File Shares has the following limitations:

Unsupported VSS capabilities, such equally: hardware transferrable shadow copies, writable shadow copies, VSS fast recovery where a volume tin quickly revert to a shadow re-create, and client-accessible shadow copies (Shadow Copy of Shared Folders).
Loopback configurations where an application server accesses its information on SMB file shares that are hosted on the same application server.
Shadow copies of Hyper-V virtual machines, where the awarding for which the virtual machine stores its data on SMB file shares is not supported.
Data on mounted drives that are below the root of the file share are non included in the shadow copy.
Shadow copies of file shares that do non support failover clustering.

Deployment scenarios

VSS for SMB File Shares is most commonly deployed with Hyper-V, where a server running Hyper-V stores the virtual machine files on remote SMB file share. Some example deployments are described below.

Unmarried server running Hyper-V and unmarried file server

In this scenario, there is a unmarried, non-clustered server running Hyper-V and a unmarried, not-amassed file server. As shown in the diagram below, the file server has 2 volumes attached to it, with a file share on each volume. The virtual auto files for VM A are stored on \\fileserv\share1, which is backed by Book i. For VM B, some of the virtual machine files are stored on \\fileserv\share1, and some are stored on \\fileserv\share2, which is backed by Book 2. The virtual machine files for VM C are stored on \\fileserv\share2.

Diagram of a single server running Hyper-V and a single file server

When a backup operator performs a shadow re-create of VM A, the Hyper-V VSS writer adds \\fileserv\share1 to the shadow copy set. When set, the File Share Shadow Copy Provider sends the shadow copy request to \\fileserv. On the file server, the File Share Shadow Copy Agent invokes the local VSS service to perform a shadow copy of Volume 1. Volume 2 is not part of the shadow re-create set since only \\fileserv\share1 was reported by the VSS writer. When the shadow copy sequence is complete, a shadow copy share \\fileserv\share1@{GUID} is available for the backup application to move the backup data. When the backup is complete, the backup awarding releases the shadow copy set, and the associated shadow copies and shadow copy shares are removed.

If the backup operator performs a shadow re-create of VM B, the Hyper-V VSS writer reports both \\fileserv\share1 and \\fileserv\share2 in the shadow re-create set. On the file server, this results in a shadow copy of both Volume ane and Volume 2, and two shadow copy shares \\fileserv\share1@{GUID} and \\fileserv\share2@{GUID} are created.

If the backup operator performs a shadow copy of VM A and VM B, the Hyper-V VSS author reports both \\fileserv\share1 and \\fileserv\share2 in the shadow re-create set up. On the file server, a shadow copy of both volumes is generated and two shadow copy shares are created.

Two servers running Hyper-V and a file server cluster

In this scenario, there are two servers running Hyper-Five and a file server cluster. As shown in the diagram below, the file server cluster has two cluster nodes, node1 and node2. The file server cluster, \\fs1, is currently online on node1, with a unmarried share, \\fs1\share, on Volume 1. To employ both cluster nodes, a second file server cluster, \\fs2, is configured and is currently online on node2, with a unmarried share, \\fs2\share, on Volume ii.

Diagram of two servers running Hyper-Five and a file server cluster

When the backup operator performs a shadow re-create of VM A, the Hyper-V VSS writer reports \\fs1\share in the shadow re-create set. When set, the File Share Shadow Re-create Provider sends a shadow copy request to \\fs1. Every bit part of the commutation between the File Share Shadow Re-create Provider and the File Share Shadow Copy Agent, the agent notifies the provider of the concrete computer proper noun, node1, which is actually performing the shadow re-create.

On node1, the File Share Shadow Copy Agent calls the local VSS service to perform a shadow copy of the volume that backs the file share. When the shadow copy sequence is consummate, a shadow re-create share \\node1\share@{GUID} is available for the fill-in application to stream the backup data. Note the shadow copy share, \\node1\share@{GUID}, is targeted to the cluster node, node1, and not the virtual computer name, \\fs1.

In one case the backup is complete, the fill-in awarding releases the shadow copy set and the associated shadow copies and shadow copy shares are removed. If the file server cluster moves to, or fails over to, node2 before the backup sequence is complete, the shadow copy share and the shadow copy go invalid. If the file server cluster moves dorsum to node1, the shadow copy and the corresponding shadow copy share will become valid again.

Step ane: Install File Server VSS Agent Service

Utilise i of the post-obit procedures to install File Server VSS Amanuensis Service.

To install File Server VSS Agent Service using Server Manager

From the Add Roles and Features Wizard, under Server Roles, select File and Storage Services if it has non already been installed.
Under File and iSCSI Services, select File Server and File Server VSS Agent Service.
On the Select Features page, click Next.
On the Confirmation folio, verify that File Server and File Server VSS Agent Service are listed, and so click Install.

The side by side office of Pace 1 is where you include the Windows PowerShell equivalent to the GUI process. Delete this part if there is no PowerShell equivalent.

Windows PowerShell equivalent commands

The following Windows PowerShell cmdlet or cmdlets perform the same office every bit the preceding procedure. Enter each cmdlet on a single line, fifty-fifty though they may appear word-wrapped across several lines here because of formatting constraints.

Provide the Windows PowerShell lawmaking for the process. For instance:

              PS C:\> Import-Module ServerManager PS C:\> Add-WindowsFeature -name File-Services,FS-VSS-Agent

Step ii: Add together a user to the Fill-in Operators local group on the file server

The user who is performing the shadow re-create must have the backup authoritative privileges on the remote file servers that are included in the shadow copy set. Normally, this is accomplished by adding the user to the Fill-in Operators group on the file servers. Use one of the post-obit procedures to do this.

To add a user to the Fill-in Operators local group on the file server using Server Manager

From the dashboard in Server Managing director, click Tools, and and then click Calculator Management.
In Computer Direction, expand Local Users and Groups, then aggrandize Groups.
Double-click Backup Operators.
On the Fill-in Operators Properties folio, click Add.
Blazon of the name of the user yous want to add to the Backup Operators group, and click OK.

Windows PowerShell equivalent commands

The following Windows PowerShell cmdlet or cmdlets perform the same function as the preceding procedure. Enter each cmdlet on a single line, even though they may appear word-wrapped across several lines hither because of formatting constraints.

In the example below, modify the user account and the name of the file server to apply to your surroundings.

              $objUser = [ADSI]("WinNT://domain/user") $objGroup = [ADSI]("WinNT://fileserv/Backup Operators") $objGroup.PSBase.Invoke("Add",$objUser.PSBase.Path)

Stride 3: Perform a shadow copy

You lot must accept a VSS-aware backup application that supports VSS for SMB File Shares to perform a shadow copy of an application's information that is stored on a remote file share.

Note

Windows Server Backup in Windows Server 2012 or in Windows Server 2012 R2 does non back up VSS for SMB File Shares.

This section contains examples of performing a shadow re-create of a virtual machine that has its data files stored on an SMB file share using DiskShadow.exe (a tool that exposes the functionality offered by VSS), and Microsoft System Heart Information Protection Managing director 2012 Service Pack 1. For information on how to backup and protect information using Microsoft Arrangement Heart Information Protection Managing director 2012 SP1, see Managing Hyper-V computers.

To perform a shadow copy of virtual motorcar on the Hyper-V host (HV1) using DiskShadow

Outset Windows PowerShell. Right-click the PowerShell icon on the taskbar, and select Run as Administrator.

Run the following Windows PowerShell command:
```
                  PS C:\Users\administrator> DISKSHADOW                                  
```

Type the following:

                  DISKSHADOW> Writer Verify {66841cd4-6ded-4f4b-8f17-fd23f8ddc3de} DISKSHADOW> Prepare Context Persistent DISKSHADOW> Fix MetaData vm1backup.cab DISKSHADOW> Brainstorm Fill-in DISKSHADOW> Add Book \\smbsofs\vm\vm1 DISKSHADOW> Create

The following output appears:

                  Alias VSS_SHADOW_1 for shadow ID {7b53b887-76e5-4db8-821d-6828e4cbe044} ready as environment variable. Alias VSS_SHADOW_SET for shadow set ID {2bef895d-5d3f-4799-8368-f4bfc684e95b} fix equally environs variable. Querying all shadow copies with the shadow re-create set ID {2bef895d-5d3f-4799-8368-f4bfc684e95b} * Shadow copy ID = {7b53b887-76e5-4db8-821d-6828e4cbe044} %VSS_SHADOW_1% - Shadow copy set: {2bef895d-5d3f-4799-8368-f4bfc684e95b} %VSS_SHADOW_SET% - Original count of shadow copies = 1 - Original book name: \\SMBSOFS\VM\ [volume not on this machine] - Cosmos fourth dimension: 5/xxx/2012 5:35:52 PM - Shadow copy device name: \\FSF-260403-09\VM@{F1C5E17A-4168-4611-9CD4-8366F9F935C3} - Originating machine: FSF-260403-09 - Service auto: CONTOSO.SMBTEST.stbtest.microsoft.com - Not exposed - Provider ID: {89300202-3cec-4981-9171-19f59559e0f2} - Attributes: No_Auto_Release Persistent FileShare Number of shadow copies listed: 1

Type the following to cease the fill-in operation:

                  DISKSHADOW> End Backup

In this instance, the following command parameters are used:

Writer Verify. This parameter specifies that the backup or restore operation must fail if the author or the component is non included. For more information, see Invoking diskshadow to back up a Virtual Machine from a Hyper-5 Host.

Set Context Persistent. This parameter sets the shadow copy to exist persistent, which means that the user or the application controls when to delete the shadow copy.

Gear up MetaData. This parameter stores the metadata information for the shadow copy (which is needed for restore) in the specified file.

Add Volume. This parameter adds the UNC path to the shadow copy prepare. Yous can specify multiple paths by repeating the Add together Volume parameter.

Create. This parameter initiates the shadow copy. When the shadow re-create is created, DiskShadow generates the properties of the shadow copy. The shadow Copy device proper noun is the path for the shadow copy information, which tin exist copied to the backup store using XCOPY or other tools.

Annotation

During the backup session, you can come across the virtual motorcar status reporting Backing up.. in Hyper-5 Manager. The fill-in session starts with the Create parameter, and and so ends with the Terminate Fill-in command in the DiskShadow sequence above.

To copy the backup data to an alternate location

Later on the shadow copy is consummate, you tin view the shadow re-create share (which is the shadow copy device name from above), and and then copy the data you want to back up to an alternate location.

Offset Windows PowerShell. Right-click the PowerShell icon on the taskbar, and select Run every bit Administrator.

Run the post-obit Windows PowerShell control:

                  PS C:\Users\administrator> Get-ChildItem -Recurse -Path "\\FSF-260403-09\VM@{F1C5E17A-4168-4611-9CD4-8366F9F935C3}" Directory: \\FSF-260403-09\VM@{F1C5E17A-4168-4611-9CD4-8366F9F935C3} Mode LastWriteTime Length Name ---- ------------- ------ ---- d---- vm1 Directory: \\FSF-260403-09\VM@{F1C5E17A-4168-4611-9CD4-8366F9F935C3}\vm1 Mode LastWriteTime Length Name ---- ------------- ------ ---- d---- vm1 -a--- vm1.vhd Directory: \\FSF-260403-09\VM@{F1C5E17A-4168-4611-9CD4-8366F9F935C3}\vm1\vm1 Mode LastWriteTime Length Name ---- ------------- ------ ---- d---- Virtual Machines Directory: \\FSF-260403-09\VM@{F1C5E17A-4168-4611-9CD4-8366F9F935C3}\vm1\vm1\Virtual Machines Mode LastWriteTime Length Proper name ---- ------------- ------ ---- d---- 87B27972-46C2-406B-87A4-C3FFA1FB6822 -a--- 28800 87B27972-46C2-406B-87A4-C3FFA1FB6822.xml Directory: \\FSF-260403-09\VM@{F1C5E17A-4168-4611-9CD4-8366F9F935C3}\vm1\vm1\Virtual Machines\87B27972-46C2-406B-87A4-C3FFA1FB6822 Style LastWriteTime Length Name ---- ------------- ------ ---- -a--- 2147602688 87B27972-46C2-406B-87A4-C3FFA1FB6822.bin -a--- 20971520 87B27972-46C2-406B-87A4-C3FFA1FB6822.vsv

To delete the shadow copy

When the backup information is copied, you tin delete the shadow re-create.

Beginning Windows PowerShell. Right-click the PowerShell icon on the taskbar, and select Run as Administrator.

Run the following Windows PowerShell command:
```
                  PS C:\Users\administrator> DISKSHADOW                                  
```

Blazon the post-obit:

                  DISKSHADOW> Delete Shadows Volume \\smbsofs\vm Deleting shadow re-create {7b53b887-76e5-4db8-821d-6828e4cbe044} on volume \\SMBSOFS\VM\ from provider {89300202-3cec-4981-91 71-19f59559e0f2} [Attributes: 0x04400009]... Number of shadow copies deleted: 1

To restore information from a shadow copy

Start Windows PowerShell. Right-click the PowerShell icon on the taskbar, and select Run every bit Administrator.

Run the following Windows PowerShell control:

                  PS C:\Users\ambassador> DISKSHADOW DISKSHADOW> Set Context Persistent DISKSHADOW> Load MetaData vm1backup.cab DISKSHADOW> Begin Restore DISKSHADOW> //xcopy files from backup store to the original location DISKSHADOW> End Restore

The Load MetaData parameter loads the metadata data for the shadow copy to restore information from the specified file. After running the Begin Restore parameter, you tin re-create the virtual machine files from the backup shop to the original location (\\smbsofs\vm\vm1). For more information, see this Microsoft TechNet blog.