Welcome to NetWorker Module for Microsoft (NMM) 9.0 Technical Differences.

Copyright ©2015 EMC Corporation. All Rights Reserved. Published in the USA. EMC believes the information in this publication is
accurate as of its publication date. The information is subject to change without notice.

THE INFORMATION IN THIS PUBLICATION IS PROVIDED “AS IS.” EMC CORPORATION MAKES NO REPRESENTATIONS OR WARRANTIES
OF ANY KIND WITH RESPECT TO THE INFORMATION IN THIS PUBLICATION, AND SPECIFICALLY DISCLAIMS IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Use, copying, and distribution of any EMC software described in this publication requires an applicable software license. The trademarks,
logos, and service marks (collectively "Trademarks") appearing in this publication are the property of EMC Corporation and other
parties. Nothing contained in this publication should be construed as granting any license or right to use any Trademark without the
prior written permission of the party that owns the Trademark.

Acartus, Access Logix, AdvantEdge, AlphaStor, ApplicationXtender, ArchiveXtender, Atmos, Authentica, Authentic Problems, Automated
Resource Manager, AutoStart, AutoSwap, AVALONidm, Avamar, Captiva, Catalog Solution, C-Clip, Celerra, Celerra Replicator, Centera,
CenterStage, CentraStar, ClaimPack, ClaimsEditor, CLARiiON, ClientPak, Codebook Correlation Technology, Common Information Model,
Configuration Intelligence, Configuresoft, Connectrix, CopyCross, CopyPoint, Dantz, DatabaseXtender, Data Domain, Direct Matrix
Architecture, DiskXtender, DiskXtender 2000, Document Sciences, Documentum, elnput, E-Lab, EmailXaminer, EmailXtender , EMC2,
EMC, EMC Centera, EMC ControlCenter, EMC LifeLine, EMC OnCourse, EMC Proven, EMC Snap, EMC SourceOne, EMC Storage
Administrator, Enginuity, eRoom, Event Explorer, FarPoint, FirstPass, FLARE, FormWare, Geosynchrony, Global File Virtualization,
Graphic Visualization, Greenplum, HighRoad, HomeBase, InfoMover, Infoscape, Infra, InputAccel, InputAccel Express, Invista, Ionix,
ISIS, Max Retriever, MediaStor, MirrorView, Navisphere, NetWorker, nLayers, OnAlert, OpenScale, PixTools, Powerlink, PowerPath,
PowerSnap, QuickScan, Rainfinity, RepliCare, RepliStor, ResourcePak, Retrospect, RSA, the RSA logo, SafeLine, SAN Advisor, SAN Copy,
SAN Manager, Smarts, SnapImage, SnapSure, SnapView, SRDF, StorageScope, SupportMate, SymmAPI, SymmEnabler, Symmetrix,
Symmetrix DMX, Symmetrix VMAX, TimeFinder, UltraFlex, UltraPoint, UltraScale, Unisphere, VMAX, Vblock, Viewlets, Virtual Matrix,
Virtual Matrix Architecture, Virtual Provisioning, VisualSAN, VisualSRM, Voyence, VPLEX, VSAM-Assist, WebXtender, xPression, xPresso,
YottaYotta.

NetWorker Module for Microsoft (NMM) 9.0 Technical

Copyright 2015 EMC Corporation. All rights reserved. Differences 1
 This course covers various NetWorker Module for Microsoft (NMM) enhancements and changes
included in NetWorker 9.0. Topics include NMM simplification, support for pre-9.0 NMM clients,
and changes to NMM for Microsoft SQL and SharePoint VDI, Exchange and Hyper-V backups.

NetWorker Module for Microsoft (NMM) 9.0 Technical

Copyright 2015 EMC Corporation. All rights reserved. Differences 2
 In order to interact with its audience and to provide students the opportunity to ask questions
related to the content of NetWorker 9.0 Technical Differences courses, EMC Education Services
has created a common place on Inside EMC. The incoming comments/questions are monitored
by Education Services instructors who will respond to them. Students are encouraged to visit
the forum, post their own questions, participate in discussions, and browse through the
questions and comments posted by others.

This common place is accessible on the following URL-

https://inside.emc.com/groups/technical-education-emc/projects/networker-90-tech-
differences.

NetWorker Module for Microsoft (NMM) 9.0 Technical

Copyright 2015 EMC Corporation. All rights reserved. Differences 3
 We will begin the module by looking at NMM simplification and the changes for configuring
backups and recoveries in NMM 9.0. Next, we’ll look at the SharePoint and SQL VDI 9.0
enhancements. At the end of this module, you will run a video that demonstrates how to
install NMM 9.0 and how to use the new backup command.

NetWorker Module for Microsoft (NMM) 9.0 Technical

Copyright 2015 EMC Corporation. All rights reserved. Differences 4
 The changes and enhancements in the NetWorker Module for Microsoft 9.0 release can be
summed up in one word, simplification. This includes a new architecture model for VSS
backups, re-designed media database footprint, use of the new 9.0 data protection policies for
backup, simplified backup and recovery logging, the introduction of block based backups for
Exchange and Hyper-V, and synthetic full backups with Data Domain.

Why make all these changes? NMM simplification means improvements in backup and recovery
performance, removing complex and time-consuming maintenance of different architecture
layers, and removing the restrictions on workflows to enable new features such as block based
backups. We’ll take a look at each of these features in this course.

NetWorker Module for Microsoft (NMM) 9.0 Technical

Copyright 2015 EMC Corporation. All rights reserved. Differences 5
 Before NMM 9.0, NMM architecture and workflow were very complex, consisting of multiple
components for backup and interaction with the Microsoft VSS framework. Also, there were
multiple products to be installed as part of NMM including the NetWorker client as a base,
multiple application logics, PowerSnap for data movement and snapshot life cycle
management, and Replication Manager as the VSS requestor. All these components
contributed to product complexity. In addition, if there were problems, it could be difficult to
determine where to look for troubleshooting.

With NMM 9.0 simplification, NMM uses the VSS Common Requestor for all VSS framework
related operations and workflows, replacing Replication Manager. PowerSnap’s snapshot
management is no longer needed in NMM 9.0. NetWorker uses the traditional Save for SQL
Server and SharePoint VSS backups and the block based backup framework for Hyper-V and
Exchange server backups. VSS hardware providers are not supported.

You can see what a difference these changes have made in reducing complexity by comparing
the pre-NMM 9.0 diagram on the left with the NMM 9.0 diagram on the right.

NetWorker Module for Microsoft (NMM) 9.0 Technical

Copyright 2015 EMC Corporation. All rights reserved. Differences 6
 Prior to NMM 9.0, there were three logging models in NMM: one for NMM, one for Replication
Manager and a third for PowerSnap. With 9.0, NMM reduces the logging model to just NMM
logs. In the new model, there is a single log file for NMM save and a single log file for NMM
recover.

NetWorker Module for Microsoft (NMM) 9.0 Technical

Copyright 2015 EMC Corporation. All rights reserved. Differences 7
 The records stored in the media database for pre-NetWorker 9.0 NMM VSS backups are
depicted in the diagram on the left. They include records for snapshot save sets and rollover
save sets linked to cover save sets. All are linked to the snapshot session ID.

With NetWorker 9.0, the media footprint is much less complex. There is a metadata record
that is linked to the save set records for the application data.

NetWorker Module for Microsoft (NMM) 9.0 Technical

Copyright 2015 EMC Corporation. All rights reserved. Differences 8
 Prior to NetWorker 9.0, the backup process model for NMM VSS backups included seven
processes involved in a backup. Nsrexecd spawned nsrsnap that spawned
nsrsnap_vss_sv and on to more processes. With the 9.0 NMM client, nsrexecd initiates
one process, nsrnmmsv, and that is it! And for recover, the recovery client interface starts
one process, nsrnmmrc.

Consequently, the nsrsnap_vss_save and nsrsnap_vss_recover commands are no

longer used for VSS backup and recovery. They are replaced by the new backup command,
nsrnmmsv, and the new recovery command, nsrnmmrc. Here is an example of specifying
nsrnmmsv when creating a SQL client configuration for a VSS backup.

NetWorker Module for Microsoft (NMM) 9.0 Technical

Copyright 2015 EMC Corporation. All rights reserved. Differences 9
 With NetWorker Module for Microsoft 9.0, NMM takes full advantage of the new 9.0 data
protection policies and workflows for both VSS and VDI backups. NMM backups use the same
types of actions as traditional backups. The snapshot policies used in previous NMM versions
for VSS backups are no longer used. Performing a backup with NMM 9.0 is done by creating a
workflow containing a backup action.

After creating a client resource, you create a protection group and add the client resource to
the group. Then, after creating a policy, you create a workflow in the policy and assign the
protection group to the workflow. The workflow specifies when and how often the actions in
the workflow will run. The number of backups taken per day is controlled by the schedule
times of the workflow.

Workflows enable you to run one or more actions either sequentially or in parallel. Actions
supported for backup operations are probe, check connectivity, backup and clone. A clone
action can be configured to occur after the backup action or it can be an action in a separate
workflow by using a save set or a query group type to specify the save sets to clone.

Here, we see an example of a backup workflow for a SQL VSS backup. In this example, the
client resource was added to a new group called SQLVSS which was associated with a new
workflow in the Bronze policy called SQLVSS. This workflow consists of one action, a backup
action. As part of the action configuration, a pool consisting of a Data Domain device was
chosen for backup storage.

NetWorker Module for Microsoft (NMM) 9.0 Technical

Copyright 2015 EMC Corporation. All rights reserved. Differences 10
 The table shows the backup levels for VSS backups performed to Data Domain and AFTD
devices. Note that incremental backups stored on a Data Domain device are stored as virtual
synthetic full backups.

SQL and SharePoint VSS backups are only supported for backup level Full. For those types of
backups, make sure to set the schedule in the backup action to all Full. Backups configured for
any other level will fail.

NetWorker Module for Microsoft (NMM) 9.0 Technical

Copyright 2015 EMC Corporation. All rights reserved. Differences 11
 This table shows the Microsoft Exchange server version and operating systems supported by
NMM 9.0. The minimum supported OS for Exchange backups is Windows 2008 R2.

Details of the supported application versions and service packs are not shown here. For the
most up-to-date and accurate listing of hardware, operating system, service pack, and
application versions that the NMM client supports, please refer to the NetWorker Online
Software Compatibility Guide available on the EMC online support website.

NetWorker Module for Microsoft (NMM) 9.0 Technical

Copyright 2015 EMC Corporation. All rights reserved. Differences 12
 Here is a list of the supported SQL Server and OS versions for NMM 9.0. Federated backups
are supported with SQL Server 2012 and 2014 versions.

Details of the supported application versions are not shown here. For the latest, detailed
information for supported application versions and OS configurations, please refer to the
NetWorker Online Software Compatibility Guide available on the EMC online support website.

NetWorker Module for Microsoft (NMM) 9.0 Technical

Copyright 2015 EMC Corporation. All rights reserved. Differences 13
 This table shows the Microsoft SharePoint server version and operating systems supported by
NMM 9.0.

For the latest information for system requirements and supported application and OS versions,
please refer to the NetWorker Online Software Compatibility Guide available on the EMC online
support website.

NetWorker Module for Microsoft (NMM) 9.0 Technical

Copyright 2015 EMC Corporation. All rights reserved. Differences 14
 NMM 9.0 adds a new feature for SQL VDI transaction level backups to optionally turn off log
gap detection.

During SQL VDI transaction log backup operations, there are checks for existing full and
transaction log backups which are already saved for a database. This functionality is to ensure
there is a valid chain of SQL transaction logs, thereby enabling point-in-time recoveries. If a
log gap is detected, the backup is promoted to a full database backup. This is the default
behavior.

However, SQL log gap checking can take up to 5 to 30 seconds per database which can add up
to a significant amount of time in a backup of a SQL server with thousands of databases. With
NMM 9.0, the user has the option to turn off log gap detection to improve the performance for
SQL database backups.

To do this, enable the Turn off log gap detection during incremental backup option on
the client resource. By default, this option is not checked, that is, log gap detection is enabled.
This flag applies at both the database and SQL instance levels. NMM adds the flag to
application information for the backup

Note: If log gap detection is turned off, make sure there is no other backup product protecting
the SQL databases or SQL instances, including SQL native and DDBMA for SQL. When an
incremental backup is created by another backup product while log gap detection is turned off
in NetWorker, a log gap will be introduced; this will not be detected in NetWorker and the next
NetWorker backup will not be promoted to full. When a restore is performed, that backup
performed by the other product will not be included in the chain for restore because NetWorker
does not know about the backup.

NetWorker Module for Microsoft (NMM) 9.0 Technical

Copyright 2015 EMC Corporation. All rights reserved. Differences 15
 NetWorker 9.0 introduces two new backup levels for SQL VDI backups: Logs Only and
Cumulative Incr. The previous backup levels of Incremental and Differential for SQL VDI
backups are deprecated. Internally, however, things remain the same. The Logs Only backup
level will internally perform a transaction log or incremental backup. Likewise, the Cumulative
Incr level will internally perform a differential backup. It is important to note that using either
of these deprecated backup levels for NMM 9.0 SQL VDI backups will cause a backup to fail.

NetWorker Module for Microsoft (NMM) 9.0 Technical

Copyright 2015 EMC Corporation. All rights reserved. Differences 16
 With NMM 9.0 support for SharePoint federated backups, users can offload SharePoint backups
to SQL Server 2012/2014 secondary servers and databases. There is no backup load on the
primary or active SQL server or database.

NMM SharePoint federated backup support includes support for:

• Copy only full backup of an AlwaysOn database on a secondary server, available only in the
federated workflow.

• Automatic determination of the preferred node of the AlwaysOn availability group and
spawning backup on that node.

• Configuration of backup of both AlwaysOn databases and non-AlwaysOn databases via a

single cluster client. AlwaysOn database backups are indexed against the cluster client,
while the non-AlwaysOn database backups are indexed against the physical host.

NetWorker Module for Microsoft (NMM) 9.0 Technical

Copyright 2015 EMC Corporation. All rights reserved. Differences 17
 NMM 9.0 supports SharePoint Server federated backups using the
AUTOMATED_BACKUP_PREFERENCE and BACKUP PRIORITY settings made in a SQL Server
2012/2014 AlwaysOn database via SQL Management Studio. This is consistent with SQL
Server federated backups supported previous to NetWorker 9.0. These options specify the SQL
Server backup preference for the availability group and determine where the backups are run
for the given availability group.

As shown here, the Prefer Secondary option specifies that backups occur on a secondary
replica except when the primary replica is the only replica online. In that case, the backup
occurs on the primary replica. This is the default option.

NetWorker Module for Microsoft (NMM) 9.0 Technical

Copyright 2015 EMC Corporation. All rights reserved. Differences 18
 To perform federated backups using NMM, you create a client resource for the Windows cluster
name and dummy client resources for the other participating nodes in the cluster. You can
configure the client resources manually using the options available in client properties in NMC
or you can use the Client Backup Configuration wizard to create the client resources.
The Client Backup Configuration wizard guides you through the creation of all client resources
required for the backup. {click} Configuring the SharePoint machine will create the dependent
clients for SharePoint client, the Windows Cluster client, and SQL clients required for federated
backup. The wizard recognizes and displays the save sets that can be selected for backup.

Application information on the client resource for the cluster specifies the option
NSR_FEDERATED_BACKUP=yes.

Scheduled backups are performed using the traditional backup action within a data protection
policy workflow.

NetWorker Module for Microsoft (NMM) 9.0 Technical

Copyright 2015 EMC Corporation. All rights reserved. Differences 19
 From a federated backup, you can perform a normal restore to the original server or a directed
restore to other servers.
Steps to perform the recovery include:
 First, on the primary replica server, break the replication for databases that are configured
with AlwaysOn configuration.
 Next, delete the database on the machines which host the secondary replicas of the
AlwaysOn group.
 Using the NetWorker Module for Microsoft interface, select the Windows Cluster client on the
machine which hosts the primary replica of the AlwaysOn Group as shown in this example.
 Restore the database.
 Then, join or re-add the database to the Always On Group using the ‘full join’ method.

Note that using the “Join-only” option during recovery is not supported as there is no
incremental backup support with NMM SQL VSS.

NetWorker Module for Microsoft (NMM) 9.0 Technical

Copyright 2015 EMC Corporation. All rights reserved. Differences 20
 Backup of asynchronous secondary replicas will not support disaster restore. Content Database
and item-level restore using SharePoint GLR are supported by backups of asynchronous
secondary replicas.

If a SharePoint database is configured with Availability Group listener but not joined to the
AlwaysOn availability group, the database will be inaccessible from SharePoint after AlwaysOn
availability group failover happens to another node. In this case, after failover, the SharePoint
writer does not report this database.

NetWorker NMM 9.0 does not currently support SQL embedded.

NetWorker Module for Microsoft (NMM) 9.0 Technical

Copyright 2015 EMC Corporation. All rights reserved. Differences 21
 In this demonstration, we’ll look at how to install NMM 9.0 and how to use the new backup
command.

NetWorker Module for Microsoft (NMM) 9.0 Technical

Copyright 2015 EMC Corporation. All rights reserved. Differences 22
 This module covered NMM simplification, NMM 9.0 architecture and workflow changes, the use
of data protection policies with NMM, and SQL and SharePoint new features and changes.

NetWorker Module for Microsoft (NMM) 9.0 Technical

Copyright 2015 EMC Corporation. All rights reserved. Differences 23
 This module focuses on the ways that NetWorker and NMM 9.0 support pre-9.0 NMM clients.

NetWorker Module for Microsoft (NMM) 9.0 Technical

Copyright 2015 EMC Corporation. All rights reserved. Differences 24
 NetWorker and NMM 9.0 provide support for existing NMM 8.2.x and 3.0.x clients in three (3)
ways:

First, NetWorker 9.0 server supports backups and restores of existing NMM 8.2.x and 3.0.x
clients.

Second, you can upgrade NMM 8.2.x and 3.0.x clients to NMM 9.0.

And third, NMM 9.0 can restore NMM 8.2.x and 3.0.x backups.

Let’s take a look at each of these topics in more detail.

NetWorker Module for Microsoft (NMM) 9.0 Technical

Copyright 2015 EMC Corporation. All rights reserved. Differences 25
 NetWorker server 9.0 supports backup and restore operations of existing NMM 8.2.x and 3.0.x
clients.

When the NetWorker server is migrated to version 9.0, the existing group resources are
migrated to NetWorker 9.0 protection policies, workflows, backup actions and groups. The
function of groups in 9.0 is now solely for selection of clients in workflows. Clients belong to
9.0 groups with the same group names as before migration. After migration, when a backup
containing a pre-9.0 client resource is initiated, the NetWorker server needs to determine
which values to use for pool, storage node, backup level and retention policy. This is done
based upon the value of the Client Override Behavior attribute of the backup action
associated with each client resource. Initially after migration, the Client Override Behavior is
set to Legacy Backup Rules. When using legacy backup rules, NetWorker uses the pool
specified in the client resource. If a pool is not specified in the client resource, it uses the pool
selection attributes in the pool resources. The values for storage node, backup level and
retention period are taken from the client resource. Where not specified in the client resource,
the value from the equivalent attribute in the backup action is used. This behavior remains in
effect until the Client Override Behavior attribute in the backup action is changed. Other
values for the attribute are Client Can Override, where values in the client resource for pool,
storage node, backup level and retention period take precedence over the values defined in
the backup action. If an attribute in the client resource is empty, then the value specified in
the equivalent attribute in the backup action is used. If the Client Override Behavior is set
to Client Can Not Override, then NetWorker uses the values for pool, storage node, backup
level and retention period specified in the backup action.

NetWorker Module for Microsoft (NMM) 9.0 Technical

Copyright 2015 EMC Corporation. All rights reserved. Differences 26
 NetWorker server 9.0 supports ad-hoc backups initiated by pre-9.0 NMM clients. If the ad-hoc
backup operation is initiated without specifying a pool, storage node and/or group, NetWorker
will look for a workflow that contains the client and use the information from that backup
action. The backup fails if no associated workflow can be found.

Sequential cloning actions are supported.

NetWorker Module for Microsoft (NMM) 9.0 Technical

Copyright 2015 EMC Corporation. All rights reserved. Differences 27
 You can upgrade NMM pre-9.0 releases to NMM 9.0. The NetWorker server, storage node and
client must be upgraded to release 9.0 before upgrading NMM to 9.0. Before doing the NMM
upgrade, make sure you are familiar with the requirements and procedures provided in the
NMM Installation Guide and NetWorker updating guides.

Because pre-9.0 NMM snapshot policies are not applicable in NMM 9.0, you may want to
manually rollover any existing snapshots before upgrading to NetWorker 9.0.

The NetWorker push upgrade feature can be used for standalone NetWorker clients for
NetWorker 8.1.1 or later and NMM 3.0 or later. Note that a direct upgrade cannot be
performed for NMM releases prior to NMM 3.0 and for clustered clients. To install without using
the push feature, first remove the existing client and NMM software and then perform an
install of NetWorker 9.0 client and NMM.

NetWorker Module for Microsoft (NMM) 9.0 Technical

Copyright 2015 EMC Corporation. All rights reserved. Differences 28
 When upgrading to 9.0, pre-9.0 NMM client resources are not modified as part of the server
migration or NMM upgrade process. For example, the backup command for VSS backups is not
changed. These older NMM client resources are not compatible with NW 9.0 and must be
modified before a successful backup can be run. This can be done automatically by running the
Modify Client Wizard or manually by modifying the properties of the client resource. To
manually upgrade pre-9.0 client resources, these changes are required:

• Change the VSS backup command from nsrsnap_vss_save.exe to nsrnmmsv.exe

• For SharePoint, remove C:\inetpub and System Components from the Save set
attribute if they are present

• For VDI backups, clear the schedule information in the client resource and choose a
comparable new backup level and schedule in the backup option

Changing the contents of the Application Information field is not required as NMM 9.0 will
ignore any obsolete parameters in the Application Information field and log a message in
the application log noting the unsupported application information. An exception is the
NSR_VSS_FULL_Backup variable for Hyper-V client resources. In NMM 9.0, the behavior of
this variable has changed. To continue with the pre-9.0 behavior, you must specify
NSR_VSS_FULL_BACKUP=no in the Application Information field and backups will be
performed as Copy type backups. If the NSR_VSS_FULL_Backup variable is not specified in
the Application Information field or if the variable is set to “yes”, Hyper-V VM backups are
enabled (initial full, subsequent incrementals).

Note: You can use NMC bulk edit to change multiple client resources.

NetWorker Module for Microsoft (NMM) 9.0 Technical

Copyright 2015 EMC Corporation. All rights reserved. Differences 29
 NMM 9.0 supports restores of pre-9.0 SQL VDI and Active Directory backups with no changes.

NMM 9.0 supports the restores of previous NMM 8.2.x and 3.0.x VSS backups through the
installation of an additional component available from the NMM 9.0 installer. Snapshot restores
and restores of Microsoft Data Protection Manager are not supported. A reboot of the NMM
host server is required after the installation.

To enable this functionality, the NetWorker 9.0 Extended client package, lgtoxtdclnt-
9.0.x.x.exe, must be installed first. Then, in the NMM 9.0 installer, select the Restore
previous NMM release backups option. This installs NMM 8.2.1 binaries and the Eldos driver
to support Granular Level Restores (GLR). On the wizard completing screen, select Restart to
complete the installation and reboot the host.

After the installation, there will be two shortcuts on the desktop for launching an NMM GUI:
one for restoring current backups and one for restoring previous backups. This component is
installed in a separate folder, rpnvmm, under \nsr; recover logs are generated in the
\nsr\rpvnmm\applogs folder.

Note that this component can be installed during the initial installation of NMM 9.0 or, if you
later realize that you need to install an older backup, you can install it then.

NetWorker Module for Microsoft (NMM) 9.0 Technical

Copyright 2015 EMC Corporation. All rights reserved. Differences 30
 This module covered the three ways that NetWorker and NMM 9.0 provide support for existing
NMM 8.2.x and 3.0.x clients: NetWorker server 9.0 supports backup and restore operations of
existing NMM 8.2.x and 3.0.x clients, pre-9.0 NMM clients can be upgraded to NMM 9.0, and
NMM 9.0 supports restores of NMM 8.2.x and 3.0.x backups.

NetWorker Module for Microsoft (NMM) 9.0 Technical

Copyright 2015 EMC Corporation. All rights reserved. Differences 31
 This module focuses on using the block based backup (BBB) feature for NMM Exchange
backups and the user configuration tool.

NetWorker Module for Microsoft (NMM) 9.0 Technical

Copyright 2015 EMC Corporation. All rights reserved. Differences 32
 NMM 9.0 for Exchange introduces several changes and enhancements for Microsoft Exchange
Server backups.

NMM 9.0 for Exchange software only backs up to AFTD or Data Domain devices and does not
support other device types.

The backups performed by NMM 9.0 for Exchange exclusively are VSS backups of the type
Exchange VSS full. VSS full backups truncate the transaction logs and other application log
files. This has the effect of making some third party incremental backups of the Exchange
server impossible causing all those backups to be full backups. The logs files are
truncated/deleted up to a checkpoint taken at the backup start time.

NetWorker Module for Microsoft (NMM) 9.0 Technical

Copyright 2015 EMC Corporation. All rights reserved. Differences 33
 technology to write the backup. This means that only the blocks that are in use are backed up.
For incremental backups, only the blocks that have changed since the last backup will be
written to the backup device.

NetWorker Module for Microsoft (NMM) 9.0 Technical

Copyright 2015 EMC Corporation. All rights reserved. Differences 34
 Backups to Data Domain devices will always be stored as virtual synthetic full backups.

DAG based backups are configured as federated DAG backups by default.

NetWorker Module for Microsoft (NMM) 9.0 Technical

Copyright 2015 EMC Corporation. All rights reserved. Differences 35
 NMM 9.0 for Exchange uses BBB exclusively in its backing up of data.

The first backup of an Exchange deployment gathers both the Exchange database files and the
Exchange application log files.

NetWorker Module for Microsoft (NMM) 9.0 Technical

Copyright 2015 EMC Corporation. All rights reserved. Differences 36
 There are two types of BBB mechanisms implemented in NMM 9.0 for Exchange. The first
mechanism, Write Tracker driver (WT) is reserved for the Exchange database file only. The
second mechanism is used for all other types of data and is known as Change Block Tracking
(CBT).

The Write Tracker driver maintains a bitmap, in memory, to track the changes to the blocks of
the database. If the system is rebooted, the Write Tracker driver must reinitialize and start a
new full backup of the database to create the block tracking bitmap in memory. This behavior
is by design.

CBT uses a map of all the blocks on a volume to track changes. The map is a set of bits where
every bit corresponds to a single block on disk. After a backup, all of the bits are set to 0. This
means that no changes have occurred yet. When a block on disk is changed, CBT updates the
map changing that block’s mapped bit from 0 to 1. CBT maps are retained between system
reboots.

NetWorker Module for Microsoft (NMM) 9.0 Technical

Copyright 2015 EMC Corporation. All rights reserved. Differences 37
 NMM 9.0 for Exchange supports an Incremental Forever backup strategy with Data Domain
and AFTD devices. When backing up to an AFTD, there is a mandatory promotion to a full
backup after the 38th consecutive incremental backup. This maximum is important to know
when architecting your backup plan; you don’t want all your full backups kicking off on the
same day!

NMM 9.0 for Exchange software will also force an incremental backup to a full backup under
several other conditions. These include:

When the Exchange database is migrated or moved to a new server or location.

When changing the target device where the backups are stored.

When the BBB framework promotion logic dictates that a promotion to a full backup is
required. This can happen when the system is rebooted, the WT detects that the WT bitmap
has been corrupted, the paths for the Exchange database or Exchange logs are changed, and
the volume size where the Exchange logs or the Exchange databases are located change size.

NetWorker Module for Microsoft (NMM) 9.0 Technical

Copyright 2015 EMC Corporation. All rights reserved. Differences 38
 NMM 9.0 comes with a user configuration tool. The configuration tool is designed to simplify
the creation and management of users with privileges to perform backup and recovery
operations on the Exchange server. The tool runs automatically after installation of NMM 9.0
for Exchange and can also be run at any time by a domain administrator.

There are three tasks the Exchange Admin Configuration tool can perform: Configure Admin
User, Update Admin Password, and Validate an existing admin.

To use the Exchange Admin Configuration tool a user must be logged in with Domain
Administrator permissions.

Use the Configure Admin User function to create an NMM Exchange administrator account.
Supply the user name and password for the user and specify the database to be used by the
user. This creates an Active Directory NMM Exchange administrator account and configures the
appropriate permissions and memberships to perform Exchange database restore and granular
level recovery. This action will also create an Exchange security group called EMC NMM
Exchange Admin Roles.

Update Admin Password updates the password for an NMM Exchange administrator account
for backup and recovery where NMM is installed.

The Validate an existing user function verifies the configuration of the supplied user and
reports back if the user is correctly configured to run NMM Exchange administrator backups
and recoveries.

NetWorker Module for Microsoft (NMM) 9.0 Technical

Copyright 2015 EMC Corporation. All rights reserved. Differences 39
 In this demonstration, we’ll look at the how to implement block based backups for Exchange
including how to use the User Configuration tool.

NetWorker Module for Microsoft (NMM) 9.0 Technical

Copyright 2015 EMC Corporation. All rights reserved. Differences 40
 This module covered the block based backup feature for NMM Exchange backups and the user
configuration tool.

NetWorker Module for Microsoft (NMM) 9.0 Technical

Copyright 2015 EMC Corporation. All rights reserved. Differences 41
 This module focuses on Hyper-V enhancements with NMM 9.0 including block based backup
(BBB) protection, using virtual intelligent proxies for CSV backups, and performing file level
recoveries for Hyper-V virtual machines.

NetWorker Module for Microsoft (NMM) 9.0 Technical

Copyright 2015 EMC Corporation. All rights reserved. Differences 42
 NetWorker Module for Microsoft has expanded to take advantage of the features in Microsoft
Hyper-V for Windows Server 2012 and 2012R2. NMM utilizes block based backup (BBB)
technology for all Hyper-V backups. BBB analyzes the object being protected and backs up
only the blocks that have changed. This prevents having to back up the entire file
unnecessarily. As a result of incorporating BBB, NetWorker uses two new features: Change
Block Tracking (CBT) and Partial Writer support.

To make CBT possible for Hyper-V VMs, a new WMI property was introduced by Microsoft
called IncrementalBackupEnabled, which is enabled in the OS by default. Now, incremental
backups of VMs are possible. Using the incremental forever backup strategy, new VMs receive
a full backup first and subsequent incremental backups. Synthetic full backups are produced
from the combination of a full backup and incremental backups. Backup and recovery using
these methods result in quicker completion times.

NetWorker also takes advantage of Hyper-V 2012 and 2012R2 Partial Writer support. By
specifying this option in the client backup configuration, the backup of a large scale
deployment of VMs continues toward completion, even if an individual VM is found in a bad
state. The savegroup will show a status of passed despite any VMs that fail to create a
snapshot.

NetWorker Module for Microsoft (NMM) 9.0 Technical

Copyright 2015 EMC Corporation. All rights reserved. Differences 43
 Because BBB is the only supported backup technology for NMM Hyper-V, backups have a few
restrictions to be aware of.

Data Domain and AFTD device types are the only supported backup devices.

Recoveries using NMM version 3.0.x or newer are only permitted if the Restore previous
NMM release backups option was selected during the NMM install.

Block based backups do not support data files that are encrypted, compressed or deduplicated.

VSS hardware providers are not supported.

NetWorker Module for Microsoft (NMM) 9.0 Technical

Copyright 2015 EMC Corporation. All rights reserved. Differences 44
 Special considerations exist if you are deploying NMM for Hyper-V in either a standalone or
cluster Hyper-V environment.

For standalone block based backups, configure the Hyper-V client resources for Hyper-V server
backups. This can be done in the NetWorker Management Console. Specify the physical
hostname as the client. The additional protection elements, such as the policies and workflows,
must be configured specifically for Hyper-V. For example, an incremental forever strategy
should be chosen as the policy for Data Domain target devices. If using AFTD, it is best
practice to use “Incremental Forever, Full on 1st of Month.” Otherwise, a Full will be performed
automatically after the 38th incremental backup. This is to prevent long chains of differencing
disks in Hyper-V.

For clusters using CSV and federated backups, deployment is slightly different. The client
resource must be created for the cluster virtual server name instead of the physical
hostnames. The policy guidelines are the same as standalone servers. All VMs in the Hyper-V
cluster will be included in the save set. This includes any new VM clusters added to Hyper-V
later on. However, any standalone VMs in the same Hyper-V server as clustered VMs must be
managed as separate client resources.

NetWorker Module for Microsoft (NMM) 9.0 Technical

Copyright 2015 EMC Corporation. All rights reserved. Differences 45
 NetWorker Module for Microsoft permits the use of Hyper-V VMs to perform as virtual proxy
backup hosts . This allows for multiple VM backups to be performed in parallel on either
Cluster Shared Volumes (CSV) or Server Message Block (SMB) volumes.

In this simple architecture diagram, we have a three node cluster utilizing a virtual cluster
name as client identification. The virtual cluster name serves as a main proxy host and chosen
VMs perform as the virtual proxy hosts. The virtual proxies can work in parallel with physical
proxies to intelligently load balance all the CSVs during backups to ensure better backup
performance.

NetWorker Module for Microsoft (NMM) 9.0 Technical

Copyright 2015 EMC Corporation. All rights reserved. Differences 46
 Implementing virtual proxies requires adding additional clients in the NetWorker Management
Console. It is recommended to use the Client Configuration wizard.

1. Start by creating a client for the virtual cluster name. This serves as the main proxy client.
Additional clients need to be created for each physical cluster host as well as the VMs that
will serve as the proxy hosts.

2. The virtual proxy hosts should be clustered VMs that are part of the same domain as the
physical hosts. NetWorker Module for Microsoft will need to be installed on each virtual
proxy host.

3. The main proxy client requires additional application attributes to be enabled in the client
configuration. Distribute the backup workload across the virtual proxy hosts by including
them in the Preferred Server Order List (PSOL). Also, ensure CSV ownership can change
during the backup operation to take advantage of intelligent load balancing. This ensures
CSVs are owned by the virtual proxy hosts for backing up VM files. By default, the
MOVE_CSV_OWNERSHIP option is set to Yes.

NetWorker Module for Microsoft (NMM) 9.0 Technical

Copyright 2015 EMC Corporation. All rights reserved. Differences 47
 In environments where virtual proxy hosts are utilized, the underlying backup workflow is
similar to a multi-proxy backup with physical machines as proxies. A mix of physical and
virtual proxy hosts are permitted.

1. When a backup is started in a CSV environment, a list is generated of CSV ownership for
the group of VMs to be backed up.

2. Those CSVs are moved to the physical host, or coordinating node, where the different
proxies are running.

3. A separate save operation occurs to take snapshots of the CSV volumes. The snapshot can
occur from any cluster node.

4. The completed snapshot is mounted to the physical host where a corresponding CSV was
moved previously.

5. Each of the virtual proxy hosts start a data-rollover job from the shared snapshots for the
save sets assigned to them. This technique eliminates network traffic and maximizes
backup performance.

6. When the rollover is complete the cluster owner notifies the backup host.

The restore is a transparent operation. It has not changed from the previous version of
NetWorker.

NetWorker Module for Microsoft (NMM) 9.0 Technical

Copyright 2015 EMC Corporation. All rights reserved. Differences 48
 New in NMM is File Level Recovery (FLR) for Hyper-V. FLR is a web GUI which permits the
backup administrator to recover individual files and download them through a supported
browser or restore them directly to a Hyper-V VM. The application follows a step-by-step
process to recover the backup files. The backup administrator has access to search and
recover files for all the VMs backed up to the NetWorker server. During the recovery process,
monitoring is possible by clicking Restore Monitor located at the bottom of the GUI. There
are two different work flows an administrator can choose; a browser download restore and a
directed restore.

NetWorker Module for Microsoft (NMM) 9.0 Technical

Copyright 2015 EMC Corporation. All rights reserved. Differences 49
 A “browser download restore” allows the administrator to download the backup to a local folder
or network location.

• Follow the steps in the GUI, as reviewed on the previous slide, to locate the backup files
you wish to recover.

• When the files are found, ensure the Restore to a browser download location option is
enabled on the Restore Options page and click Finish.

• Follow the progress of the recovery using the Restore Monitor.

• Once the restore process is complete, in the Restore Monitor, click the Download button
to save the recovered files. Choose the local folder or network path to save the recovered
files.

NetWorker Module for Microsoft (NMM) 9.0 Technical

Copyright 2015 EMC Corporation. All rights reserved. Differences 50
 The recovered files will appear in the Restore Monitor at the bottom of the page with the
option to download them. Log files can be found at C:\Program Files\EMC
NetWorker\nsr\logs\hyperv-flr-ui.

NetWorker Module for Microsoft (NMM) 9.0 Technical

Copyright 2015 EMC Corporation. All rights reserved. Differences 51
 A directed restore allows the administrator to choose a specific VM and location for the
recovered files.

• The process of locating the files is the same as the browser download workflow.

• After the Restore Options page is reached, ensure the Restore to a browser download
location option is disabled.

• New choices are available in the GUI where the VM and destination file path can be
determined.

• Direct the restore to the VM and location for the recovered files and click Finish. Follow the
progress of the recovery using the Restore Monitor.

NetWorker Module for Microsoft (NMM) 9.0 Technical

Copyright 2015 EMC Corporation. All rights reserved. Differences 52
 The recovered files will appear in the Restore Monitor at the bottom of the page showing the
VM and location where the recovered files were directed. Log files can be found at
C:\Program Files\EMC NetWorker\nsr\logs\hyperv-flr-ui.

NetWorker Module for Microsoft (NMM) 9.0 Technical

Copyright 2015 EMC Corporation. All rights reserved. Differences 53
 The Hyper-V FLR GUI components are installed automatically with the NetWorker server
software. However, additional configuration is required to identify the Hyper-V servers and
VMs. The following example illustrates one possible implementation.

1. First, install the NetWorker client and then the NetWorker Module for Microsoft software on
the Hyper-V server.

2. Next, ensure the NetWorker Module for Microsoft Recovery Agent service is installed and
running. It should be located in the nsr\bin directory.

3. Finally, if you want to perform directed restores to a VM, perform the installation of the
Proxy Recovery Adapter on the VMs. The executable file will need to be copied from the
Hyper-V server to the VMs manually. The file is located at \EMC NetWorker\nsr\NMM
ProxyRA\x64 (or x86) on the Hyper-V host. Install the service from the command line
by running the executable with the “-add” option , then start the service from the
command line or Service Management . If you are only doing download restores, nothing
needs to be loaded on the VM.

NetWorker Module for Microsoft (NMM) 9.0 Technical

Copyright 2015 EMC Corporation. All rights reserved. Differences 54
 4. Once the installation is complete, launch the GUI from NMC by going to the Recover tab,
select the Recover menu and choose Launch Hyper-V File Level Restore UI. You may
also enter the URL of the NetWorker server hostname and port 10,000 in a supported web
browser. Log in to the GUI as a NetWorker administrator who is part of the NetWorker
Security Administrator and Application Administrator user groups.

5. In the Settings tab of FLR, specify a proxy URL . This will be the IP or FQDN of the server
where NetWorker Module for Microsoft is installed.

6. The list of Hyper-V servers will be available in the FLR GUI . Select the Hyper-V server to
display the VMs with available backups. You can now follow the steps as described in the
previous slides to recover files from the VMs.

NetWorker Module for Microsoft (NMM) 9.0 Technical

Copyright 2015 EMC Corporation. All rights reserved. Differences 55
 In this demonstration, we’ll look at the how to implement block based backups for backups of
Hyper-V virtual machines.

NetWorker Module for Microsoft (NMM) 9.0 Technical

Copyright 2015 EMC Corporation. All rights reserved. Differences 56
 This module covered block based backups for NMM Hyper-V, intelligent virtual proxies and the
new file level recovery GUI for Hyper-V virtual machines.

NetWorker Module for Microsoft (NMM) 9.0 Technical

Copyright 2015 EMC Corporation. All rights reserved. Differences 57
 Please consult these guides and other NetWorker reference materials for more information
about the topics presented in this course. Also, please refer to the online NetWorker Software
Compatibility Guide for the most up-to-date information about supported versions.

NetWorker Module for Microsoft (NMM) 9.0 Technical

Copyright 2015 EMC Corporation. All rights reserved. Differences 58
 This course covered various NetWorker Module for Microsoft (NMM) enhancements and
changes included in NetWorker 9.0. Topics included NMM simplification, NetWorker and NMM
9.0 support for pre-9.0 NMM clients and backups, and changes to NMM for SQL VDI,
SharePoint, Exchange and Hyper-V backups.

This concludes the training. Please proceed to the course assessment on the next slide.

NetWorker Module for Microsoft (NMM) 9.0 Technical

Copyright 2015 EMC Corporation. All rights reserved. Differences 59