Work Folders on Windows Server 2012 R2 supports only local storage, i.e. the sync share location must be a local path on the server.

As we talked to customers, many of them use a NAS device for individual user data storage (e.g. home folders, user redirected folders), and they wish Work Folders can sync those data to user devices.

I'd like to recruit a few customers who are willing to collaborate closely with us on this feature development. If you are using offline files for user data which is stored by a NAS device, and migrate to Work Folders while keeping the data on the NAS devices, please share your contact info with me here:

http://aka.ms/smbgateway

Hi all, Ned here again. Our colleagues from the Microsoft “Customers, Architecture, and Technologies” team have started a new Windows Server 2016 storage technology video series. These are the folks who work with a small set of customers on pre-lease software. They are scenario focused and are very knowledgeable about what we’ve been building for the past two years.

Ryan Sokolowski – good Irish name, that – has kicked things off with five in depth videos on Storage QoS. He has Storage Replica vids coming soon, and a number of other hush-hush things in the pipe.

Here’s a taste. There are many more.

Storage QoS MultiInstance Policies (it rolls off the tongue)

Get on over there and see how Windows Server 2016 will change your life and business for the better.

  - Ned “has a Polish stepmother, so it’s all good” Pyle

Stefano Gagliardi asked a question on how to limit the network traffic for Work Folders. I know Work Folders client doesn't do it, but there might be other controls at the network layer. Stefano being the network expert did find a solution, and I asked him to share it, so we can all learn from it.

Below is the blog post from Stefano, enjoy!

**********************************

Hi there!

This is Stefano Gagliardi, Windows and Azure Networking specialist from Europe, and big Work Folders fan!

I sync all my data from my laptop to my server in the office. I just love the way it keeps everything up to date without even having to worry about it! I need my files to be ready and accessible on my server within a short time, so I cannot wait for scheduled backups: Work Folders does a great job for me by synchronizing the data as soon as it is modified on my laptop, without any delay.

Since I have hundreds of Gigabytes of files, my problem is now the bandwidth that gets consumed in order to sync all the data over the network, especially when I work from home where my upload bandwidth is limited.

All the network resources are dedicated to the file synchronization, leaving little to no bandwidth for other applications.

There is a very simple solution to this problem: you can limit the bandwidth used by Work Folders in order to not saturate your network!

You will need to create a QoS Policy on your client with these steps:

• Open gpedit.msc to access the Local Group Policy Editor
• Expand Computer Configuration / Windows Settings
• Right-click on Policy-Based QoS and Create a new Policy

• Follow the Wizard by assigning the policy a name of your choice, and the Maximum Bandwidth that you want to allow the Work Folders service. You don’t need to specify a DSCP value.

• On the Next page, Apply the policy to just applications named svchost.exe

• On the Next page, specify the IP address of the Work Folders server.

 TIP: by configuring the Direct Access IPv6 address of the Work Folder server, you will apply the bandwidth limit only when connecting remotely via DA. This way, Syncronization inside the office LAN where more bandwidth is available will not be slowed down.

• Finally, apply the policy only to TCP destination port 443. 

If you are a Windows expert, you might have noticed that we have applied the policy to a particular application, svchost.exe. As you know, this process is the container process for most of the builtin services of the operating system – including the Work Folders client service – so you may be worried that we are limiting the bandwidth for many other Windows activities. This is not a concern, because by applying the filter to only TCP 443 of the Work Folder server, we are sure that no other running service will be impacted.

What happens after applying the Policy is that the Work Folder service (green) now only pushes data up to a certain limit and i have bandwitdh left for other task that require low latency, like for example VoIP applications (blue)

In our testing, we found an issue in Work Folders which breaks sync after upgrade from Windows 7 to Windows 10. The root cause is the Work Folders sync partnership was not maintained, as a result, sync will stop. To fix it, user will need to go to Control panel, and setup the Work Folders partnership again. However, since the partnership has removed, there is no warning nor notification to the user about the issue.

To address this problem, we released a QFE to Windows 7, so the Work Folders client can continue to sync after the upgrade.

The QFE download is here: https://support.microsoft.com/en-us/kb/3081954

If you are using Work Folders on Windows 7, it's important to install this QFE.

Earlier this year, in January and April, we released the Work Folders app for Apple® iPad and iPhone.
Since its release, a lot of work has been done to integrate Work Folders with the larger ecosystem to help enhance enterprise control and protection of corporate owned data inside the Work Folders app.

With the recent iOS app refresh, we are now releasing Work Folders integration with a series of products that enables enterprises to have more granular control over their data. 
 

• RMS
  Work Folders is now integrated with the Rights Management Service (RMS) which encrypts and protects individual files, no matter where they travel. Our integration is centered around the newer
  .p-file format for RMS protected files. This way an enterprise can ensure that any highly sensitive information cannot easily be accessed by an unauthorized person.
  A current limitation is that natively encrypted office files (non .p-files) cannot be viewed in the Work Folders app for this release.
  
  
  The Work Folders app supports RMS deployed on-prem or the use of the Azure RMS online service. 
  Using RMS with Work Folders provides an organization with the utmost level of file security on devices. Files are always encrypted while in the Work Folders application and the user must be authorized by a token-based authentication in order to view a file. This feature combination is ideal for organizations where file security is essential and the integration in the Work Folders app provides a streamlined user experience.

  Links:

  • Active Directory Rights Management Services Mobile Device Extension 

  • Coming soon: We will release another blog post containing detailed steps for configuring Work Folders to use RMS.
    
     

• Microsoft Intune
  Work Folders is now integrated with Microsoft Intune, a mobile device management service (MDM).
  Using Intune and Work Folders together improves an organization’s capabilities to accomplish the following :

  • Prevent a file from leaving the Work Folders app
    Using Windows Intune, you can now set a policy that prevents the Work Folders user to “open-in” a file into another application, thus making a copy of the file and handing over control over the file to the other app.
    
    Why is it important to limit open-in?
    Work Folders keeps your files safe. The files are encrypted at all times independent of the device’s encryption settings. When a user opens the file in another app, however, Work Folders is forced to hand the file over to the next application, stripped of the Work Folders encryption layer (other file encryption, such as RMS, remains intact).
    
    The receiving application may or may not be controlled by your organization as it can be any application on the device that has registered to handle the file type.
    Preventing open-in for the Work Folders app prevents the file from leaving the controlled Work Folders environment altogether.
     
    Outside of Work Folders, Intune offers a policy to disable open-in for the entire device and not just the Work Folders app. This policy is less useful on devices that are shared between personal use and work use as users are less likely to tolerate the absence of the widely used iOS feature for their personal use. The Work Folders collaboration with Intune gives you a precision instrument to affect only corporate data.

  • Enforce universal PIN
    Work Folders protects access to the app through an App-PIN, at all times.
    Once the device is under Intune management and there is a universal App-PIN configured by Intune, Work Folders will respect the superior PIN and substitute the Work Folders app-PIN for the universal one. That enables the user to have a single PIN across all managed apps. This PIN policy is managed by the organization and provides a common restore experience.

  • Perform targeted Remote wipe
    When using an MDM such as Intune, an organization has the ability to remotely wipe an entire device. As devices are often used for both personal and business, it has long since become a blocker for users to get their device under management when an organization can wipe the entire device.
    A more precise solution is needed. With Work Folders and Intune, you now have a precision instrument to remotely wipe just the Work Folders encrypted files from the Work Folders app, leaving the rest of the device intact.
    A user has to properly re-authenticate to use Work Folders again as they would on any device where Work Folders is setup for the first time.
    
    We will soon release a blog post explaining how to configure Work Folders to use ADFS as its authentication solution and link to this post from here.
    
     

Registered Devices only
When using Work Folders with an ADFS authentication solution, the Work Folders app can be configured to only authenticate a user on a device that is registered with your organization. Device registration is typically done through an MDM, such as Microsoft Intune. The requirement for this feature is ADFS configured on a Windows Server 2016, Technical Preview 4 or later.

With the release of Windows Server Technical Preview 4, I’d like to send one primary message to all of our customers using or evaluating Windows Server Data Deduplication (which I assume applies to you since you are reading this posting!): Test at full scale!

I’ve seen the telemetry from hundreds of dedup installations using Windows Server TP3 and it’s great to see that a full range of usage types are being evaluated and that the functionality is performing just as we expected.

[Note: For the details about all the new dedup features in Windows Server 2016, see the Data Deduplication in Windows Server Technical Preview 3 article which summarizes all the changes. ]

What I’d like to see now are more configurations testing dedup at full scale.

What do I mean by test at full scale?  Basically the following:

• Large volume sizes: Up to 64TB if you can! Volumes at 32TB or larger are of interest as well.

• Large file sizes: Files up to 1TB used for any supported scenario!

• Large data churn: Workloads that modify or create new data across the volume. The ability of a system to process the full data churn depends heavily on the nature of the workload and data as well as on the system’s hardware capabilities.  Evaluating your heaviest loads on the systems you expect to use is the best way to ensure your scenarios are optimally supported by the final release.

We did make some final scale improvements to the dedup job algorithms based on direct feedback from TP3, so we strongly believe that TP4 has everything you need for your large scale deduplication scenarios. (That statement should be enough to get even the most skeptical of you give it a try :-)

And as always we would love to hear your feedback and results. Please send email to dedupfeedback@microsoft.com and let us know how your evaluation goes and, of course, any questions you may have.

Thanks!

Recently, Matt Hrynkow from Microsoft helped a customer to deploy Work Folders, and we talked about how to plan for disaster recovery (DR), I thought it will be good to share the details.

Overview

The purpose of DR is to return a system to a state of normality after an occurrence of a disastrous event. In the context of Work Folders, there are two main goals:

1. Allow users to continue access their data, i.e. user experience minimum to no downtime when the server failed.

2. Allow IT admin to bring the server back online and resume client sync.

Note: DR plan is not intended to recover user deleted files. There are other features in Windows such as File history can be evaluated for individual file restore.

Unlike traditional file servers, where the data is only stored on the server, Work Folders being a sync technology, has data stored at multiple locations. Each sync client (e.g. user windows or iOS devices) and the sync server (i.e. Windows 2012 R2 file server) has a local copy of the same data for a given user. With Work Folders, user can always access their data on their devices even when the Work Folders server is down. This is very different from the traditional file share, where user access depends on the availability of the file server. Work Folders server failure results to user data not being synced across multiple devices, because the device sync depends on the server availability to mediate the process.

In general, two methods for data recovery can be utilized.  You can either use the client data to replenish the server copy, or you can replicate the server data to another server at another site to pre-stage the file set. 

Recovery using client data

If a user typically has a single device in your environment, and devices are always connected to file server through high speed connections, you may evaluate the option for recovery using only the client data copy. Using this approach, after a primary server failure, you can configure the replacement, and the client will re-upload the data to the server once the replacement is up and running. The advantage is that you don’t need to have a standby server and storage, and the downside is the network can be busy when the replacement server is put in place, and all the clients try to upload their data. Dataset size vs network bandwidth should be carefully evaluated for this option.

Export Work Folders server configuration

If you plan to use the client data for recovery after DR scenario, you should keep track of the sync share configurations on the server to ease the setup on the replace server.

You can run the following cmdlet on the Work Folders server to get all the sync share settings:

Get-SyncShare | Export-Clixml -path c:\temp\config.xml

And later run the import cmdlet on the replacement server to configure the sync share settings:

Import-CliXML –Path c:\temp\config.xml | New-SyncShare

Certificate

To have the client automatic sync with the replacement server, you can use the same server name on the replacement server. To ensure the certificate works on the replacement server, you need to export the certificate you have acquired for the original Work Folders server (if you are using the same server name) with the private key, then install the .pfx file on the new server.

User doesn’t need to do anything; the sync will continue after the replacement server is configured.

DR using server to server replication

For DR planning, you need to be aware of 2 types of data for Work Folders:

1. File data: the actual file set to be synced across clients and server.

2. Metadata database: tracking the file set version and sync status.

In order to resume sync successfully after DR scenario, the following initial data states on the secondary server (or replacement server) are acceptable:

1. No data present: No file set nor metadata database on the replacement server. Once sync starts, client will upload the data to the server.

2. Only file data is present: once sync starts, it will reconcile the data, and generate the metadata database on the replacement server.

3. Both file data and metadata database are present, and they are in a consistent state. It’s important to ensure the database and the file data are in a consistent state, otherwise data loss may occur. Using VSS snapshot with the Work Folders VSS writer for example, will make sure the database and the file set are in a consistent state; however, doing file copy of the file data and metadata database will not guarantee the data in a consistent state.

Different DR planning will result in different initial data states on the secondary server, and each with its pros and cons, to be discussed below.

DR recommendations

At a high level, there are 3 options you can consider:

1. Using BCDR (business continuity and disaster recovery) products: many storage products offer block level replication, if your data is stored on these products, you may consider leverage them to build the DR plan. These products need to guarantee the data replication order, and data consistency at a given point in time.

2. Using VSS backup and restore: Many VSS backup products offer incremental backups, you can configure the snapshot to be taken daily, and restore the file data and metadata database to the secondary server after primary server failure.

3. Scheduled file replication with Windows applications (e.g. Robocopy or DFSR): make sure only the file data is getting replicated, and not the metadata database. After failover, the client and server will reconcile the data, and create the metadata database on the replacement server.

Deployment guidance

Using BCDR products

I’ll not go into details for this option, as the configuration depends on the BCDR product. You need to follow the guidance of the BCDR products, make sure the file data and the metadata database is in the same replication group, so that the IO ordering is maintained across these data set, and the product can guarantee the data consistency between the file data and the metadata database for any given point in time.

Using VSS backup and restore

Using VSS doing backup and restore with the Work Folders VSS writer can keep the consistency between the file set and the metadata database on the server. Depending on the VSS backup application, you need to configure the backup using the Work Folders VSS writer.

Upon restore, both file data and the metadata will be restored to the replacement server. The data restored on the server using VSS is called “non-authoritative” restore. That means, the files restored on the server could be overwritten by the client, if there are newer changes made on the client.

(note: In contrast, there is another mode of VSS restore called “authoritative restore” by copy and paste files from the backup. The restored files will be treated as a newer version, and will overwrite the client copy through sync, even when the client may actually have a newer copy in comparison to the restored file. This approach can be used to recover individual corrupted files when necessary, but not a focus for this blog).

Using the non-authoritative restore, when the client comes to sync, the sync engine will be able to compare the file versions between the client (current) and the server (restored at a past point in time), and sync the changes between client and the server.

File replication with Robocopy or DFSR

This approach is not recommended, because:

• It scans the entire sync share every time for changes, this can be expensive on the server if there are many files

• When the file changes are detected, Work Folders sync and file replication app may compete in opening the files, and increase the failures for both file sync and file replication app.

• You will need to actively monitor file replication progress, to ensure the app can continue successfully. (Work Folders sync will be able to retry after getting concurrency errors).

• You must exclude the sync share state folder on the server for file replication (both staging files and metadata database). After failover, the metadata database must not be present before syncsharesvc service starts. This will trigger data reconciliation. This process may have a performance impact on the server if the file set is large.

• Before the secondary server is put in action, make sure file replication (from primary server to secondary server) is stopped, so that after client starts to sync with the secondary server, changes will not be deleted, and may result data loss.

• Due to lack of metadata database tracking with file changes, any changes on the client during the time of server failover can become a conflict file, or delete files can come back, moved directories may surface again. Although not data loss, but user will need to manually figure out what to keep, and what to delete/move again.

• Need to ensure of the user folder ownership is properly replicated. Work Folders can only sync the data if the user folder ownership is property maintained as the user or local admin on the replacement server.

However, if you don’t have any VSS backup application and want to use file replication application to build a poor man DR solution, you can follow the steps below to set it up:

1. Assuming sync server for client connection is https://workfolders.contoso.com

2. Configure 2 servers (server1 and server2) with the same sync shares. (Note you can use the cmdlet listed in the Export Work Folders server configuration section to export and import the settings)

3. Configure DNS A records for server1 and server2

4. Configure DNS CNAME record for WorkFolders, and point to server1. Configure a desired TTL on the record to facilitate an acceptable time for clients to “notice” the record change when required by the client.

5. Get server certificate with hostnames including: WorkFolders.contoso.com; server1.contoso.com and server2.contoso.com

6. Configure certificate on both server1 and server2 (details on how to configure certificate can be find here).

7. For robocopy, you can run the following cmd to replicate data and the ACLs of the data

Robocopy \\<server1>\sharename \\<server2>\sharename /MIR /SEC

1. For DFSR, make sure it is the shares on Server 2 are configured read-only, to make sure the file replicate is only from server 1 to server 2.

2. Have client configure Work Folders against https://workfolders.contoso.com

Server1 failed, and you want to failover to the secondary server (e.g. server 2)

1. Stop file replication app on server1

2. On Server2, net stop syncsharessvc

3. On Server2, delete the sync share metadata database which can be found VolumeDrive:\SyncShareState\<SyncShareName>

4. On server2, net start syncsharesvc

5. Wait for TTL time so clients purge the record from their DNS cache.

6. Switch DNS by configuring DNS CNAME record of WorkFolders to point to server2

7. Client automatically initializes new client sync and starts to sync to the new server2

Conclusion

Although all 3 options are supported, we recommend DR using BCDR products or VSS backup and restore approach, as the secondary server will be in a data consistency state after failover. As you can see from the steps, using file replication app is very error prone, and may result in data loss if the procedures are not followed correctly.

Ever since Work Folders was released in Windows 8.1, the most frequently asked question is how Work Folders different from OneDrive for Business. The short answer is, Work Folders is the sync client for file server, and OneDrive for Business is the sync client for SharePoint.

While the comparison between file servers and SharePoint is out of the scope for this blog post, I found this TechNet article to be useful if you are researching whether to use SharePoint or file server for the user data storage. Once you decide on the infrastructure, the rest is simple. Work Folders offers data access stored on file servers on a variety of devices, and the devices can be on corpnet or over the internet; and OneDrive for Business will do the same when data is on SharePoint.

While I’m not the expert on SharePoint/OneDrive for Business, I get to learn a lot from many customer discussions, and in this blog post, I’ll share my view on the differences between Work Folders and OneDrive for Business.

Both Work Folders and OneDrive for Business are improving through releases, the table above only captures the current view, and for sure they will change over time. When making the choices, think about the backend infrastructure first, i.e. file server vs SharePoint.

I also want to acknowledge the feedback on providing a consistent user experience between Work Folders and One Drive for Business, and I welcome you to share your thoughts on that in comments below, specifically help me to understand what consistent user experience mean to you. Thank you.

With the latest Windows 10 Nov release, Work Folders can be surfaced as a location where user can easily access the document under it.

This new feature is announced on this page: http://windows.microsoft.com/en-in/windows-10/work-folders-in-windows-10. In this blog post, I’d like to share some more details on the user experience, and how you can enable this on Windows 7 machines.

Background

Office team offered a way for storage provider to register the service with Microsoft Office, so that the location will automatically appear in Open and Save As user interface in Office 2013 applications. You can find the details here: https://www.microsoft.com/en-us/download/details.aspx?id=35474. The same extension is offered in Microsoft Office 2016, with a slight change in the provider registration GUID format, which I’ll explain in this blog post.

Work Folders in Windows 10 builds in the support for this, and allow users to easily add Work Folders to the locations, you can also enable this capability on Windows 7 clients with some prep work.

Add a place

On Windows 10 devices with Nov update, Work Folders by default registered with Office applications. You can open any office applications, and navigate to Add a Place in Open/Save As, and you will be able to see the following:

Click on the Work Folders item, it adds the Work Folders as one of the location links associated with the user account, and you only need to do this once on one of your clients.

Open/Save As

Once the location is added, when you open or save as any office applications, Work Folders will be shown like the following:

Click on the Work Folders item will directly goes to the Work Folders path on the client, makes the access much easier.

Known issues

Because of the location list is associated with the user account, and if you are using mixed office versions, you may see both Work Folders (Office 2013) and Work Folders (Office 2016). You can find more details on the known issues here: http://social.technet.microsoft.com/wiki/contents/articles/32881.troubleshooting-using-work-folders-as-a-place-in-microsoft-office.aspx

Windows 7

Work Folders for Windows 7 released a while back, and it doesn’t do registration with the Office applications. You can enable this by adding the following registry keys, and make sure to provide the correct path for the LocalFolderRoot:

(Notice below the regkey path for Office 2013 is the GUID without {}, and the regkey for Office 2016 is the GUID with {})

Registry key for Office 2013 plugin:

[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\Common\Cloud Storage\F02A2795-066C-47BA-936F-1517BA462169]

"LocalFolderRoot"=<Work Folders path on the client>

"DisplayName"="Work Folders (Office 2013)"

"Description"="Use Work Folders to make your work files available on all devices you use, even when offline."

"LearnMoreURL"="http://go.microsoft.com/fwlink/?LinkId=623357"

"ManageURL"="http://go.microsoft.com/fwlink/?LinkId=623357"

 [HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\Common\Cloud Storage\F02A2795-066C-47BA-936F-1517BA462169\Thumbnails]

"Url16x16"="http://i-technet.sec.s-msft.com/dynimg/IC826548.jpeg"

"Url20x20"="http://i-technet.sec.s-msft.com/dynimg/IC826549.jpeg"

"Url24x24"="http://i-technet.sec.s-msft.com/dynimg/IC826550.jpeg"

"Url32x32"="http://i-technet.sec.s-msft.com/dynimg/IC826551.jpeg"

"Url40x40"="http://i-technet.sec.s-msft.com/dynimg/IC826552.jpeg"

"Url48x48"="http://i-technet.sec.s-msft.com/dynimg/IC826553.jpeg"

Registry key for Office 2016 plugin:

[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\Common\Cloud Storage\{F02A2795-066C-47BA-936F-1517BA462169}]

"LocalFolderRoot""=<Work Folders path on the client>

"DisplayName"="Work Folders (Office 2016)"

"Description"="Use Work Folders to make your work files available on all devices you use, even when offline."

"LearnMoreURL"="http://go.microsoft.com/fwlink/?LinkId=623357"

"ManageURL"="http://go.microsoft.com/fwlink/?LinkId=623357"

 [HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\Common\Cloud Storage\{F02A2795-066C-47BA-936F-1517BA462169}\Thumbnails]

"Url16x16"="http://i-technet.sec.s-msft.com/dynimg/IC826548.jpeg"

"Url20x20"="http://i-technet.sec.s-msft.com/dynimg/IC826549.jpeg"

"Url24x24"="http://i-technet.sec.s-msft.com/dynimg/IC826550.jpeg"

"Url32x32"="http://i-technet.sec.s-msft.com/dynimg/IC826551.jpeg"

"Url40x40"="http://i-technet.sec.s-msft.com/dynimg/IC826552.jpeg"

"Url48x48"=”http://i-technet.sec.s-msft.com/dynimg/IC826553.jpeg”

Once the registry keys are added, Work Folders will be surfaced as a place can be added, and you can go through the actions described in “Add a Place” to add Work Folders in any Office applications.

A popular request from our customer base for Windows Server Data Deduplication has been to support the Hyper-V scenarios (i.e., VDI and virtualized backup) on storage local to the Hyper-V server. This “hyper-converged” configuration uses a single server or cluster for hosting the VDI or virtualized backup guest workloads and dedup is enabled on local storage (as an alternative to using a separate file server).

We’ve been working to validate this configuration and I have good news – we now have sufficient internal validation and experience with preview customers to support a limited version. The limitation is primarily to schedule the dedup processing for a time window where the VDI or virtualized backup workloads are idle.

The section below defines the specific requirements for this configuration along with recommendations for validation and support. There is also an updated version of the whitepaperLarge scale Virtual Desktop Infrastructure deployment using Windows Server 2012 R2 with Storage Tiers and Data Deduplicationthat includes this information in the context of VDI applications.

Support exception for limited, scheduled dedup processing on a hyper-converged Hyper-V configuration

The configuration of enabling Windows Server Data Deduplication on data volumes directly mounted on a Hyper-V compute server (as opposed to mounted from a shared folder hosted on a separate file server) is not supported in the general case. However, there is a useful, limited configuration that is supported as an exception. This configuration is designed to avoid the occurrence of priority and/or resource conflicts between the Hyper-V guest workloads and data deduplication host partition processing by using appropriate scheduling.

For this limited configuration, deduplication must be running in a supported scenario as defined in the TechNet article Plan to Deploy Data Deduplication. In particular, open VHD files used for accessing storage in guest virtual machines are only supported for VDI and virtualized backup scenarios.

This limited configuration consists of the following:

• Hyper-V compute server or cluster dedicated to running VDI or virtualized backup guest workloads

  • All server nodes are running Windows Server 2012 R2 with the November 2014 update rollup for Windows Server 2012 R2 (KB 3000850) or later.

• Guest VHDs are stored in locally attached data volumes. In a cluster configuration the volumes are mounted as Cluster Shared Volumes.

• Windows Server Data Deduplication is enabled on these locally attached data volumes.

• All deduplication tasks on a given server or cluster are scheduled to run in a limited “idle” timeframe when all VDI or virtualized backup workloads are idle.

  • It is not required to actively enforce a block on running VDI or virtualized backup workloads during this scheduled time, but the system is required to be configured so that operation of VDI or virtualized backup is idle or paused during the scheduled dedup processing window.

• Volume sizing and deduplication performance monitoring are done in accordance with the procedures defined in the article Sizing Volumes for Data Deduplication in Windows Server.

  • If deduplication processing is not able to keep up with the daily data churn, either the “downtime” deduplication processing window must be extended or fewer simultaneous active VDI or virtualized backup workloads must be configured on the node. Also, if additional system downtime is available on weekends you can try scheduling extended dedup processing windows for weekend days.

 In addition to meeting the above requirements, the following steps are also strongly recommended:

• For VDI workloads:

  • In order to validate the VDI workload capacity of this limited configuration, run a load test using the supported VDI guest images. Tools such as LoginVSI or the equivalent should be used to directly validate the configuration prior to use in production.

  • Review the recommendations in the article Deduplication Tuning for Deployments with High Saving Rates. If the savings rates measured in the VDI deployment fall in the range covered in this article, adjust the deduplication settings as instructed.

• For virtualized backup workloads, a full backup cycle should be validated with production-equivalent workloads to ensure that the backup and deduplication jobs complete.

• An active Microsoft Service Premier Support contract is recommended to facilitate further communication, telemetry, and advice that can be useful when defining these configurations.

By the way, the support for these configurations will of course continue with the Windows Server 2016 release. It would be great if you could also use the current Technical Preview and evaluate both how this works for your hyper-converged configurations as well as how Windows Server 2016 helps you scale up, with full support for 64TB volumes and full use of up to 1TB files. See Data Deduplication in Windows Server Technical Preview 4 for all the details.

And as always we would love to hear your feedback and results. Please send email to dedupfeedback@microsoft.com and let us know about your experience with these configurations and, of course, any questions you may have.

Thanks!

Work Folders syncs files between client and server. Although most issues are discovered by users, it could be root caused on the server, the client or the network. This blog post shares the most common problems customers have reported, and some troubleshooting techniques on Windows devices.

Setup

When user setup Work Folders using Control panel app, any issues encountered will be shown in the UI. Some common issues are:

• Work Folders path cannot be encrypted: If the admin requires the files to be encrypted on the client, Work Folders will try to encrypt the folder created. If the encryption fails, user will see the failure, and ask to use a different path. A few examples:

  • If the folder handle is opened, encryption will fail.

  • If the folder is on a USB drive, and the drive is not supporting encryption.

  • There is an existing Work Folders folder, and the folder is encrypted by other keys.

  • If the device is domain joined, you may also search (then fix) expired/revoked certificate in the “Default Domain Policy”, that can prevent encryption on the client.

• Password enforcement failure: Password policy is also an admin configuration on the server, and enforced on the client. User must be an admin on the client machine to enforce the policy.

  • However, it is not common that user has local admin right for domain managed machines. To exempt password policy on domain devices, admin must configure the domains to be excluded, by using Set-SyncShare cmdlet, and specify PasswordAutolockExcludeDomain list. For example:

 Set-SyncShare <share name> -PasswordAutolockExcludeDomain <domain list>

• Password enforcement is done by the using the EAS engine in Windows. It requires that user can change password on the device. In Windows 10, EAS engine has change such that all users (including local user accounts) on that device can change password. You can find more details here (note that the MailApp also uses the EAS engine to enforce password)

• Access Denied:

  • Mirrored account: This usually happens in testing, when the device is connected to the corpnet, and logged on with a local account, and there is a domain account for the same user name as the local account. Windows may try to use NTLM to authenticate, and didn’t prompt for domain user credential (note, if you logged on as device local account, you should get prompt for domain credentials). In this case, setup will fail.

  • Windows 10 specific: This issue existed in some pre-release of Windows 10 and TH1, it is fixed in Windows 10 TH2 release. In some setup, the following regkey is missing: HKLM\Software\Microsoft\Windows\CurrentVersion\Explorer\SyncRootManager. There is no good workaround for this, recommending to get the TH2 build which has the fix in it.

Sync

Both Encryption and Password enforcement error described above can happen during sync, if the admin turns on the policy after user already setup the Work Folders. On each sync, the client will check for policy change, and apply if necessary.

For client errors, it’s always good to start with the message displayed in the Control panel. List below describe some common errors showing on the client:

• Require credential: this is more common if the admin configured ADFS for authentication. The frequency for the user to re-enter credential is defined by the ADFS token lifetime. The configuration is in ADFS. On Windows 8.1 or below, if the device is WorkPlace joined, token lifetime is 7 days by default. On Windows 10, it extends to 42 days. For non-Workplace joined devices, token lifetime is 8 hours.

• Key revoked: This happens when the encryption key was revoked by either the admin or user themselves. There are multiple ways can trigger the key revocation.

  • Admin chooses to wipe a device.

  • User removes the device from Intune management (or other MDM app if it is supported for key revocation)

  • User removes corporate email account on the device.

  • Work Folders is configured on an external drive, and the drive is connected to a different machine. The encryption key is tied to a device, when the folder is configured on one device, you can’t simply move it to another device to read it.

  • PC refresh: If the device is clean installed, the encryption key will be deleted. That will result the data unable to be decrypted.

• Conflict files: When the same file is getting modified on different devices, at the next sync time, conflict file will be generated. Work Folders determines a winner file by the last write timestamp. The winner file keeps the file name; the loser file will get renamed by appending a device name to the file name, the device name indicates where the conflict was created. Some known examples:

  • If user has changed file on one device without closing it, the file will not sync to the server, user goes to another device change the file. When both files are closed then synced, there will be conflict.

  • IE favorites: IE changes the favorite links periodically, although there is not content change, sync will detect the change, and create conflict. In Windows 10, Work Folders has optimized this by comparing content. If the file is truly identical, it will not generate conflict.

  • Server data restore: if the server lost the sync metadata database, client and server will need to compare the file sets to determine what to sync. During this reconciliation process, any differences found between the client and the server will generate conflicts.

• File types excluded from sync: Work Folders tries to optimize sync by excluding temp files and a few files specific to the device itself. The files which are excluded from sync: thumbs.db, desktop.ini and temp files (most temp files seen by Work Folders are from Office applications).

   

Client upgrade

Upgrade from Windows 7 to Windows 10, ensure the Windows 7 client has KB 3081954 is installed, otherwise, the device will lose the sync partnership to the server after upgrade. User will not be notified for any errors (since Work Folders will be shown as not installed on the device). If the user didn’t have the KB installed before the upgrade, he/she will need to re-configure Work Folders after upgrade.

From Windows 8.1 to Windows 10 upgrade, if the upgrade is done using USMT, the Work Folders link in File Explorer may not work after the upgrade. To fix this, user needs to simply open the control panel -> Work Folders, this action triggers the service to reload the partnership, and fix the link of the Work Folders path in File Explorer.

Event logs

Work Folders event logs are stored under Applications and Services -> Microsoft -> Windows -> Work Folders. The logs under Operational folder should be examined. ManagementAgent logs are used to show notification center, which can be ignored.

Traces

If the problem is not covered in any of the above or resources below, you will need to contact Microsoft CSS, who can guide you to capture the debug traces for further investigation.

Resources

The Technet wiki is also getting updated periodically when issues are reported:

http://social.technet.microsoft.com/wiki/contents/articles/tags/Work+Folders/default.aspx

If you want to learn more about Work Folders, I’d recommend the list of the blogs:

http://blogs.technet.com/b/filecab/archive/tags/work+folders/default.aspx

There are also good technet articles on Work Folders here:

https://technet.microsoft.com/en-us/library/dn265974.aspx

In our testing, we found an issue in Work Folders which breaks sync after upgrade from Windows 7 to Windows 10. The root cause is the Work Folders sync partnership was not maintained, as a result, sync will stop. To fix it, user will need to go to Control panel, and setup the Work Folders partnership again. However, since the partnership has removed, there is no warning nor notification to the user about the issue.

To address this problem, we released a QFE to Windows 7, so the Work Folders client can continue to sync after the upgrade.

The QFE download is here: https://support.microsoft.com/en-us/kb/3081954

If you are using Work Folders on Windows 7, it’s important to install this QFE.

Earlier this year, in January and April, we released the Work Folders app for Apple® iPad and iPhone.
Since its release, a lot of work has been done to integrate Work Folders with the larger ecosystem to help enhance enterprise control and protection of corporate owned data inside the Work Folders app.

With the recent iOS app refresh, we are now releasing Work Folders integration with a series of products that enables enterprises to have more granular control over their data. 
 

• RMS
  Work Folders is now integrated with the Rights Management Service (RMS) which encrypts and protects individual files, no matter where they travel. Our integration is centered around the newer
  .p-file format for RMS protected files. This way an enterprise can ensure that any highly sensitive information cannot easily be accessed by an unauthorized person.
  A current limitation is that natively encrypted office files (non .p-files) cannot be viewed in the Work Folders app for this release.

  The Work Folders app supports RMS deployed on-prem or the use of the Azure RMS online service. 
  Using RMS with Work Folders provides an organization with the utmost level of file security on devices. Files are always encrypted while in the Work Folders application and the user must be authorized by a token-based authentication in order to view a file. This feature combination is ideal for organizations where file security is essential and the integration in the Work Folders app provides a streamlined user experience.

  Links:

  • Active Directory Rights Management Services Mobile Device Extension 

  • Coming soon: We will release another blog post containing detailed steps for configuring Work Folders to use RMS.

     

• Microsoft Intune
  Work Folders is now integrated with Microsoft Intune, a mobile device management service (MDM).
  Using Intune and Work Folders together improves an organization’s capabilities to accomplish the following :

  • Prevent a file from leaving the Work Folders app
    Using Windows Intune, you can now set a policy that prevents the Work Folders user to “open-in” a file into another application, thus making a copy of the file and handing over control over the file to the other app.

    Why is it important to limit open-in?
    Work Folders keeps your files safe. The files are encrypted at all times independent of the device’s encryption settings. When a user opens the file in another app, however, Work Folders is forced to hand the file over to the next application, stripped of the Work Folders encryption layer (other file encryption, such as RMS, remains intact).

    The receiving application may or may not be controlled by your organization as it can be any application on the device that has registered to handle the file type.
    Preventing open-in for the Work Folders app prevents the file from leaving the controlled Work Folders environment altogether.
     
    Outside of Work Folders, Intune offers a policy to disable open-in for the entire device and not just the Work Folders app. This policy is less useful on devices that are shared between personal use and work use as users are less likely to tolerate the absence of the widely used iOS feature for their personal use. The Work Folders collaboration with Intune gives you a precision instrument to affect only corporate data.

  • Enforce universal PIN
    Work Folders protects access to the app through an App-PIN, at all times.
    Once the device is under Intune management and there is a universal App-PIN configured by Intune, Work Folders will respect the superior PIN and substitute the Work Folders app-PIN for the universal one. That enables the user to have a single PIN across all managed apps. This PIN policy is managed by the organization and provides a common restore experience.

  • Perform targeted Remote wipe
    When using an MDM such as Intune, an organization has the ability to remotely wipe an entire device. As devices are often used for both personal and business, it has long since become a blocker for users to get their device under management when an organization can wipe the entire device.
    A more precise solution is needed. With Work Folders and Intune, you now have a precision instrument to remotely wipe just the Work Folders encrypted files from the Work Folders app, leaving the rest of the device intact.
    A user has to properly re-authenticate to use Work Folders again as they would on any device where Work Folders is setup for the first time.

    We will soon release a blog post explaining how to configure Work Folders to use ADFS as its authentication solution and link to this post from here.

     

Registered Devices only
When using Work Folders with an ADFS authentication solution, the Work Folders app can be configured to only authenticate a user on a device that is registered with your organization. Device registration is typically done through an MDM, such as Microsoft Intune. The requirement for this feature is ADFS configured on a Windows Server 2016, Technical Preview 4 or later.

With the release of Windows Server Technical Preview 4, I’d like to send one primary message to all of our customers using or evaluating Windows Server Data Deduplication (which I assume applies to you since you are reading this posting!): Test at full scale!

I’ve seen the telemetry from hundreds of dedup installations using Windows Server TP3 and it’s great to see that a full range of usage types are being evaluated and that the functionality is performing just as we expected.

[Note: For the details about all the new dedup features in Windows Server 2016, see the Data Deduplication in Windows Server Technical Preview 3 article which summarizes all the changes. ]

What I’d like to see now are more configurations testing dedup at full scale.

What do I mean by test at full scale?  Basically the following:

• Large volume sizes: Up to 64TB if you can! Volumes at 32TB or larger are of interest as well.

• Large file sizes: Files up to 1TB used for any supported scenario!

• Large data churn: Workloads that modify or create new data across the volume. The ability of a system to process the full data churn depends heavily on the nature of the workload and data as well as on the system’s hardware capabilities.  Evaluating your heaviest loads on the systems you expect to use is the best way to ensure your scenarios are optimally supported by the final release.

We did make some final scale improvements to the dedup job algorithms based on direct feedback from TP3, so we strongly believe that TP4 has everything you need for your large scale deduplication scenarios. (That statement should be enough to get even the most skeptical of you give it a try :-)

And as always we would love to hear your feedback and results. Please send email to dedupfeedback@microsoft.com and let us know how your evaluation goes and, of course, any questions you may have.

Thanks!

Recently, Matt Hrynkow from Microsoft helped a customer to deploy Work Folders, and we talked about how to plan for disaster recovery (DR), I thought it will be good to share the details.

Overview

The purpose of DR is to return a system to a state of normality after an occurrence of a disastrous event. In the context of Work Folders, there are two main goals:

1. Allow users to continue access their data, i.e. user experience minimum to no downtime when the server failed.

2. Allow IT admin to bring the server back online and resume client sync.

Note: DR plan is not intended to recover user deleted files. There are other features in Windows such as File history can be evaluated for individual file restore.

Unlike traditional file servers, where the data is only stored on the server, Work Folders being a sync technology, has data stored at multiple locations. Each sync client (e.g. user windows or iOS devices) and the sync server (i.e. Windows 2012 R2 file server) has a local copy of the same data for a given user. With Work Folders, user can always access their data on their devices even when the Work Folders server is down. This is very different from the traditional file share, where user access depends on the availability of the file server. Work Folders server failure results to user data not being synced across multiple devices, because the device sync depends on the server availability to mediate the process.

In general, two methods for data recovery can be utilized.  You can either use the client data to replenish the server copy, or you can replicate the server data to another server at another site to pre-stage the file set. 

Recovery using client data

If a user typically has a single device in your environment, and devices are always connected to file server through high speed connections, you may evaluate the option for recovery using only the client data copy. Using this approach, after a primary server failure, you can configure the replacement, and the client will re-upload the data to the server once the replacement is up and running. The advantage is that you don’t need to have a standby server and storage, and the downside is the network can be busy when the replacement server is put in place, and all the clients try to upload their data. Dataset size vs network bandwidth should be carefully evaluated for this option.

Export Work Folders server configuration

If you plan to use the client data for recovery after DR scenario, you should keep track of the sync share configurations on the server to ease the setup on the replace server.

You can run the following cmdlet on the Work Folders server to get all the sync share settings:

Get-SyncShare | Export-Clixml -path c:\temp\config.xml

And later run the import cmdlet on the replacement server to configure the sync share settings:

Import-CliXML –Path c:\temp\config.xml | New-SyncShare

Certificate

To have the client automatic sync with the replacement server, you can use the same server name on the replacement server. To ensure the certificate works on the replacement server, you need to export the certificate you have acquired for the original Work Folders server (if you are using the same server name) with the private key, then install the .pfx file on the new server.

User doesn’t need to do anything; the sync will continue after the replacement server is configured.

DR using server to server replication

For DR planning, you need to be aware of 2 types of data for Work Folders:

1. File data: the actual file set to be synced across clients and server.

2. Metadata database: tracking the file set version and sync status.

In order to resume sync successfully after DR scenario, the following initial data states on the secondary server (or replacement server) are acceptable:

1. No data present: No file set nor metadata database on the replacement server. Once sync starts, client will upload the data to the server.

2. Only file data is present: once sync starts, it will reconcile the data, and generate the metadata database on the replacement server.

3. Both file data and metadata database are present, and they are in a consistent state. It’s important to ensure the database and the file data are in a consistent state, otherwise data loss may occur. Using VSS snapshot with the Work Folders VSS writer for example, will make sure the database and the file set are in a consistent state; however, doing file copy of the file data and metadata database will not guarantee the data in a consistent state.

Different DR planning will result in different initial data states on the secondary server, and each with its pros and cons, to be discussed below.

DR recommendations

At a high level, there are 3 options you can consider:

1. Using BCDR (business continuity and disaster recovery) products: many storage products offer block level replication, if your data is stored on these products, you may consider leverage them to build the DR plan. These products need to guarantee the data replication order, and data consistency at a given point in time.

2. Using VSS backup and restore: Many VSS backup products offer incremental backups, you can configure the snapshot to be taken daily, and restore the file data and metadata database to the secondary server after primary server failure.

3. Scheduled file replication with Windows applications (e.g. Robocopy or DFSR): make sure only the file data is getting replicated, and not the metadata database. After failover, the client and server will reconcile the data, and create the metadata database on the replacement server.

Deployment guidance

Using BCDR products

I’ll not go into details for this option, as the configuration depends on the BCDR product. You need to follow the guidance of the BCDR products, make sure the file data and the metadata database is in the same replication group, so that the IO ordering is maintained across these data set, and the product can guarantee the data consistency between the file data and the metadata database for any given point in time.

Using VSS backup and restore

Using VSS doing backup and restore with the Work Folders VSS writer can keep the consistency between the file set and the metadata database on the server. Depending on the VSS backup application, you need to configure the backup using the Work Folders VSS writer.

Upon restore, both file data and the metadata will be restored to the replacement server. The data restored on the server using VSS is called “non-authoritative” restore. That means, the files restored on the server could be overwritten by the client, if there are newer changes made on the client.

(note: In contrast, there is another mode of VSS restore called “authoritative restore” by copy and paste files from the backup. The restored files will be treated as a newer version, and will overwrite the client copy through sync, even when the client may actually have a newer copy in comparison to the restored file. This approach can be used to recover individual corrupted files when necessary, but not a focus for this blog).

Using the non-authoritative restore, when the client comes to sync, the sync engine will be able to compare the file versions between the client (current) and the server (restored at a past point in time), and sync the changes between client and the server.

File replication with Robocopy or DFSR

This approach is not recommended, because:

• It scans the entire sync share every time for changes, this can be expensive on the server if there are many files

• When the file changes are detected, Work Folders sync and file replication app may compete in opening the files, and increase the failures for both file sync and file replication app.

• You will need to actively monitor file replication progress, to ensure the app can continue successfully. (Work Folders sync will be able to retry after getting concurrency errors).

• You must exclude the sync share state folder on the server for file replication (both staging files and metadata database). After failover, the metadata database must not be present before syncsharesvc service starts. This will trigger data reconciliation. This process may have a performance impact on the server if the file set is large.

• Before the secondary server is put in action, make sure file replication (from primary server to secondary server) is stopped, so that after client starts to sync with the secondary server, changes will not be deleted, and may result data loss.

• Due to lack of metadata database tracking with file changes, any changes on the client during the time of server failover can become a conflict file, or delete files can come back, moved directories may surface again. Although not data loss, but user will need to manually figure out what to keep, and what to delete/move again.

• Need to ensure of the user folder ownership is properly replicated. Work Folders can only sync the data if the user folder ownership is property maintained as the user or local admin on the replacement server.

However, if you don’t have any VSS backup application and want to use file replication application to build a poor man DR solution, you can follow the steps below to set it up:

1. Assuming sync server for client connection is https://workfolders.contoso.com

2. Configure 2 servers (server1 and server2) with the same sync shares. (Note you can use the cmdlet listed in the Export Work Folders server configuration section to export and import the settings)

3. Configure DNS A records for server1 and server2

4. Configure DNS CNAME record for WorkFolders, and point to server1. Configure a desired TTL on the record to facilitate an acceptable time for clients to “notice” the record change when required by the client.

5. Get server certificate with hostnames including: WorkFolders.contoso.com; server1.contoso.com and server2.contoso.com

6. Configure certificate on both server1 and server2 (details on how to configure certificate can be find here).

7. For robocopy, you can run the following cmd to replicate data and the ACLs of the data

Robocopy \\<server1>\sharename \\<server2>\sharename /MIR /SEC

1. For DFSR, make sure it is the shares on Server 2 are configured read-only, to make sure the file replicate is only from server 1 to server 2.

2. Have client configure Work Folders against https://workfolders.contoso.com

Server1 failed, and you want to failover to the secondary server (e.g. server 2)

1. Stop file replication app on server1

2. On Server2, net stop syncsharessvc

3. On Server2, delete the sync share metadata database which can be found VolumeDrive:\SyncShareState\<SyncShareName>

4. On server2, net start syncsharesvc

5. Wait for TTL time so clients purge the record from their DNS cache.

6. Switch DNS by configuring DNS CNAME record of WorkFolders to point to server2

7. Client automatically initializes new client sync and starts to sync to the new server2

Conclusion

Although all 3 options are supported, we recommend DR using BCDR products or VSS backup and restore approach, as the secondary server will be in a data consistency state after failover. As you can see from the steps, using file replication app is very error prone, and may result in data loss if the procedures are not followed correctly.

Ever since Work Folders was released in Windows 8.1, the most frequently asked question is how Work Folders different from OneDrive for Business. The short answer is, Work Folders is the sync client for file server, and OneDrive for Business is the sync client for SharePoint.

While the comparison between file servers and SharePoint is out of the scope for this blog post, I found this TechNet article to be useful if you are researching whether to use SharePoint or file server for the user data storage. Once you decide on the infrastructure, the rest is simple. Work Folders offers data access stored on file servers on a variety of devices, and the devices can be on corpnet or over the internet; and OneDrive for Business will do the same when data is on SharePoint.

While I’m not the expert on SharePoint/OneDrive for Business, I get to learn a lot from many customer discussions, and in this blog post, I’ll share my view on the differences between Work Folders and OneDrive for Business.

Both Work Folders and OneDrive for Business are improving through releases, the table above only captures the current view, and for sure they will change over time. When making the choices, think about the backend infrastructure first, i.e. file server vs SharePoint.

I also want to acknowledge the feedback on providing a consistent user experience between Work Folders and One Drive for Business, and I welcome you to share your thoughts on that in comments below, specifically help me to understand what consistent user experience mean to you. Thank you.

With the latest Windows 10 Nov release, Work Folders can be surfaced as a location where user can easily access the document under it.

This new feature is announced on this page: http://windows.microsoft.com/en-in/windows-10/work-folders-in-windows-10. In this blog post, I’d like to share some more details on the user experience, and how you can enable this on Windows 7 machines.

Background

Office team offered a way for storage provider to register the service with Microsoft Office, so that the location will automatically appear in Open and Save As user interface in Office 2013 applications. You can find the details here: https://www.microsoft.com/en-us/download/details.aspx?id=35474. The same extension is offered in Microsoft Office 2016, with a slight change in the provider registration GUID format, which I’ll explain in this blog post.

Work Folders in Windows 10 builds in the support for this, and allow users to easily add Work Folders to the locations, you can also enable this capability on Windows 7 clients with some prep work.

Add a place

On Windows 10 devices with Nov update, Work Folders by default registered with Office applications. You can open any office applications, and navigate to Add a Place in Open/Save As, and you will be able to see the following:

Click on the Work Folders item, it adds the Work Folders as one of the location links associated with the user account, and you only need to do this once on one of your clients.

Open/Save As

Once the location is added, when you open or save as any office applications, Work Folders will be shown like the following:

Click on the Work Folders item will directly goes to the Work Folders path on the client, makes the access much easier.

Known issues

Because of the location list is associated with the user account, and if you are using mixed office versions, you may see both Work Folders (Office 2013) and Work Folders (Office 2016). You can find more details on the known issues here: http://social.technet.microsoft.com/wiki/contents/articles/32881.troubleshooting-using-work-folders-as-a-place-in-microsoft-office.aspx

Windows 7

Work Folders for Windows 7 released a while back, and it doesn’t do registration with the Office applications. You can enable this by adding the following registry keys, and make sure to provide the correct path for the LocalFolderRoot:

(Notice below the regkey path for Office 2013 is the GUID without {}, and the regkey for Office 2016 is the GUID with {})

Registry key for Office 2013 plugin:

[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\Common\Cloud Storage\F02A2795-066C-47BA-936F-1517BA462169]

"LocalFolderRoot"=<Work Folders path on the client>

"DisplayName"="Work Folders (Office 2013)"

"Description"="Use Work Folders to make your work files available on all devices you use, even when offline."

"LearnMoreURL"="http://go.microsoft.com/fwlink/?LinkId=623357"

"ManageURL"="http://go.microsoft.com/fwlink/?LinkId=623357"

 [HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\Common\Cloud Storage\F02A2795-066C-47BA-936F-1517BA462169\Thumbnails]

"Url16x16"="http://i-technet.sec.s-msft.com/dynimg/IC826548.jpeg"

"Url20x20"="http://i-technet.sec.s-msft.com/dynimg/IC826549.jpeg"

"Url24x24"="http://i-technet.sec.s-msft.com/dynimg/IC826550.jpeg"

"Url32x32"="http://i-technet.sec.s-msft.com/dynimg/IC826551.jpeg"

"Url40x40"="http://i-technet.sec.s-msft.com/dynimg/IC826552.jpeg"

"Url48x48"="http://i-technet.sec.s-msft.com/dynimg/IC826553.jpeg"

Registry key for Office 2016 plugin:

[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\Common\Cloud Storage\{F02A2795-066C-47BA-936F-1517BA462169}]

"LocalFolderRoot""=<Work Folders path on the client>

"DisplayName"="Work Folders (Office 2016)"

"Description"="Use Work Folders to make your work files available on all devices you use, even when offline."

"LearnMoreURL"="http://go.microsoft.com/fwlink/?LinkId=623357"

"ManageURL"="http://go.microsoft.com/fwlink/?LinkId=623357"

 [HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\Common\Cloud Storage\{F02A2795-066C-47BA-936F-1517BA462169}\Thumbnails]

"Url16x16"="http://i-technet.sec.s-msft.com/dynimg/IC826548.jpeg"

"Url20x20"="http://i-technet.sec.s-msft.com/dynimg/IC826549.jpeg"

"Url24x24"="http://i-technet.sec.s-msft.com/dynimg/IC826550.jpeg"

"Url32x32"="http://i-technet.sec.s-msft.com/dynimg/IC826551.jpeg"

"Url40x40"="http://i-technet.sec.s-msft.com/dynimg/IC826552.jpeg"

"Url48x48"=”http://i-technet.sec.s-msft.com/dynimg/IC826553.jpeg”

Once the registry keys are added, Work Folders will be surfaced as a place can be added, and you can go through the actions described in “Add a Place” to add Work Folders in any Office applications.

A popular request from our customer base for Windows Server Data Deduplication has been to support the Hyper-V scenarios (i.e., VDI and virtualized backup) on storage local to the Hyper-V server. This “hyper-converged” configuration uses a single server or cluster for hosting the VDI or virtualized backup guest workloads and dedup is enabled on local storage (as an alternative to using a separate file server).

We’ve been working to validate this configuration and I have good news – we now have sufficient internal validation and experience with preview customers to support a limited version. The limitation is primarily to schedule the dedup processing for a time window where the VDI or virtualized backup workloads are idle.

The section below defines the specific requirements for this configuration along with recommendations for validation and support. There is also an updated version of the whitepaper Large scale Virtual Desktop Infrastructure deployment using Windows Server 2012 R2 with Storage Tiers and Data Deduplication that includes this information in the context of VDI applications.

Support exception for limited, scheduled dedup processing on a hyper-converged Hyper-V configuration

The configuration of enabling Windows Server Data Deduplication on data volumes directly mounted on a Hyper-V compute server (as opposed to mounted from a shared folder hosted on a separate file server) is not supported in the general case. However, there is a useful, limited configuration that is supported as an exception. This configuration is designed to avoid the occurrence of priority and/or resource conflicts between the Hyper-V guest workloads and data deduplication host partition processing by using appropriate scheduling.

For this limited configuration, deduplication must be running in a supported scenario as defined in the TechNet article Plan to Deploy Data Deduplication. In particular, open VHD files used for accessing storage in guest virtual machines are only supported for VDI and virtualized backup scenarios.

This limited configuration consists of the following:

• Hyper-V compute server or cluster dedicated to running VDI or virtualized backup guest workloads

  • All server nodes are running Windows Server 2012 R2 with the November 2014 update rollup for Windows Server 2012 R2 (KB 3000850) or later.

• Guest VHDs are stored in locally attached data volumes. In a cluster configuration the volumes are mounted as Cluster Shared Volumes.

• Windows Server Data Deduplication is enabled on these locally attached data volumes.

• All deduplication tasks on a given server or cluster are scheduled to run in a limited “idle” timeframe when all VDI or virtualized backup workloads are idle.

  • It is not required to actively enforce a block on running VDI or virtualized backup workloads during this scheduled time, but the system is required to be configured so that operation of VDI or virtualized backup is idle or paused during the scheduled dedup processing window.

• Volume sizing and deduplication performance monitoring are done in accordance with the procedures defined in the article Sizing Volumes for Data Deduplication in Windows Server.

  • If deduplication processing is not able to keep up with the daily data churn, either the “downtime” deduplication processing window must be extended or fewer simultaneous active VDI or virtualized backup workloads must be configured on the node. Also, if additional system downtime is available on weekends you can try scheduling extended dedup processing windows for weekend days.

 In addition to meeting the above requirements, the following steps are also strongly recommended:

• For VDI workloads:

  • In order to validate the VDI workload capacity of this limited configuration, run a load test using the supported VDI guest images. Tools such as LoginVSI or the equivalent should be used to directly validate the configuration prior to use in production.

  • Review the recommendations in the article Deduplication Tuning for Deployments with High Saving Rates. If the savings rates measured in the VDI deployment fall in the range covered in this article, adjust the deduplication settings as instructed.

• For virtualized backup workloads, a full backup cycle should be validated with production-equivalent workloads to ensure that the backup and deduplication jobs complete.

• An active Microsoft Service Premier Support contract is recommended to facilitate further communication, telemetry, and advice that can be useful when defining these configurations.

By the way, the support for these configurations will of course continue with the Windows Server 2016 release. It would be great if you could also use the current Technical Preview and evaluate both how this works for your hyper-converged configurations as well as how Windows Server 2016 helps you scale up, with full support for 64TB volumes and full use of up to 1TB files. See Data Deduplication in Windows Server Technical Preview 4 for all the details.

And as always we would love to hear your feedback and results. Please send email to dedupfeedback@microsoft.com and let us know about your experience with these configurations and, of course, any questions you may have.

Thanks!

Work Folders syncs files between client and server. Although most issues are discovered by users, it could be root caused on the server, the client or the network. This blog post shares the most common problems customers have reported, and some troubleshooting techniques on Windows devices.

Setup

When user setup Work Folders using Control panel app, any issues encountered will be shown in the UI. Some common issues are:

• Work Folders path cannot be encrypted: If the admin requires the files to be encrypted on the client, Work Folders will try to encrypt the folder created. If the encryption fails, user will see the failure, and ask to use a different path. A few examples:

  • If the folder handle is opened, encryption will fail.

  • If the folder is on a USB drive, and the drive is not supporting encryption.

  • There is an existing Work Folders folder, and the folder is encrypted by other keys.

  • If the device is domain joined, you may also search (then fix) expired/revoked certificate in the “Default Domain Policy”, that can prevent encryption on the client.

• Password enforcement failure: Password policy is also an admin configuration on the server, and enforced on the client. User must be an admin on the client machine to enforce the policy.

  • However, it is not common that user has local admin right for domain managed machines. To exempt password policy on domain devices, admin must configure the domains to be excluded, by using Set-SyncShare cmdlet, and specify PasswordAutolockExcludeDomain list. For example:

 Set-SyncShare <share name> -PasswordAutolockExcludeDomain <domain list>

• Password enforcement is done by the using the EAS engine in Windows. It requires that user can change password on the device. In Windows 10, EAS engine has change such that all users (including local user accounts) on that device can change password. You can find more details here (note that the MailApp also uses the EAS engine to enforce password)

• Access Denied:

  • Mirrored account: This usually happens in testing, when the device is connected to the corpnet, and logged on with a local account, and there is a domain account for the same user name as the local account. Windows may try to use NTLM to authenticate, and didn’t prompt for domain user credential (note, if you logged on as device local account, you should get prompt for domain credentials). In this case, setup will fail.

  • Windows 10 specific: This issue existed in some pre-release of Windows 10 and TH1, it is fixed in Windows 10 TH2 release. In some setup, the following regkey is missing: HKLM\Software\Microsoft\Windows\CurrentVersion\Explorer\SyncRootManager. There is no good workaround for this, recommending to get the TH2 build which has the fix in it.

Sync

Both Encryption and Password enforcement error described above can happen during sync, if the admin turns on the policy after user already setup the Work Folders. On each sync, the client will check for policy change, and apply if necessary.

For client errors, it’s always good to start with the message displayed in the Control panel. List below describe some common errors showing on the client:

• Require credential: this is more common if the admin configured ADFS for authentication. The frequency for the user to re-enter credential is defined by the ADFS token lifetime. The configuration is in ADFS. On Windows 8.1 or below, if the device is WorkPlace joined, token lifetime is 7 days by default. On Windows 10, it extends to 42 days. For non-Workplace joined devices, token lifetime is 8 hours.

• Key revoked: This happens when the encryption key was revoked by either the admin or user themselves. There are multiple ways can trigger the key revocation.

  • Admin chooses to wipe a device.

  • User removes the device from Intune management (or other MDM app if it is supported for key revocation)

  • User removes corporate email account on the device.

  • Work Folders is configured on an external drive, and the drive is connected to a different machine. The encryption key is tied to a device, when the folder is configured on one device, you can’t simply move it to another device to read it.

  • PC refresh: If the device is clean installed, the encryption key will be deleted. That will result the data unable to be decrypted.

• Conflict files: When the same file is getting modified on different devices, at the next sync time, conflict file will be generated. Work Folders determines a winner file by the last write timestamp. The winner file keeps the file name; the loser file will get renamed by appending a device name to the file name, the device name indicates where the conflict was created. Some known examples:

  • If user has changed file on one device without closing it, the file will not sync to the server, user goes to another device change the file. When both files are closed then synced, there will be conflict.

  • IE favorites: IE changes the favorite links periodically, although there is not content change, sync will detect the change, and create conflict. In Windows 10, Work Folders has optimized this by comparing content. If the file is truly identical, it will not generate conflict.

  • Server data restore: if the server lost the sync metadata database, client and server will need to compare the file sets to determine what to sync. During this reconciliation process, any differences found between the client and the server will generate conflicts.

• File types excluded from sync: Work Folders tries to optimize sync by excluding temp files and a few files specific to the device itself. The files which are excluded from sync: thumbs.db, desktop.ini and temp files (most temp files seen by Work Folders are from Office applications).

   

Client upgrade

Upgrade from Windows 7 to Windows 10, ensure the Windows 7 client has KB 3081954 is installed, otherwise, the device will lose the sync partnership to the server after upgrade. User will not be notified for any errors (since Work Folders will be shown as not installed on the device). If the user didn’t have the KB installed before the upgrade, he/she will need to re-configure Work Folders after upgrade.

From Windows 8.1 to Windows 10 upgrade, if the upgrade is done using USMT, the Work Folders link in File Explorer may not work after the upgrade. To fix this, user needs to simply open the control panel -> Work Folders, this action triggers the service to reload the partnership, and fix the link of the Work Folders path in File Explorer.

Event logs

Work Folders event logs are stored under Applications and Services -> Microsoft -> Windows -> Work Folders. The logs under Operational folder should be examined. ManagementAgent logs are used to show notification center, which can be ignored.

Traces

If the problem is not covered in any of the above or resources below, you will need to contact Microsoft CSS, who can guide you to capture the debug traces for further investigation.

Resources

The Technet wiki is also getting updated periodically when issues are reported:

http://social.technet.microsoft.com/wiki/contents/articles/tags/Work+Folders/default.aspx

If you want to learn more about Work Folders, I’d recommend the list of the blogs:

http://blogs.technet.com/b/filecab/archive/tags/work+folders/default.aspx

There are also good technet articles on Work Folders here:

https://technet.microsoft.com/en-us/library/dn265974.aspx

With Windows Server 2016, we set out to address a customer pain point that we had observed over time: disk firmware updates. Our own experience has shown that SSDs require more frequent firmware updates than other storage devices. Requiring a storage deployment to be offline for such maintenance operations negatively affects our customers and the applications they want to run.

The Goal

The long-term goal is to provide a mechanism that allows for the updating of disk firmware with no application downtime when running on Storage Spaces.

Note: Technical Preview 4 (TP4) includes APIs and Windows PowerShell cmdlets that help you update individual disk firmware. Coordination to mitigate an impact to I/O workloads is not yet present. Firmware updates are a risky maintenance operation and you should only perform them after thorough testing of the new firmware image by the system administrator.

First Steps

To ensure common device behavior, we began by defining new and currently optional Hardware Lab Kit (HLK) requirements for SAS, SATA, and NVMe devices. These requirements outline which commands a SATA, SAS, or NVMe device has to support in order to be firmware-updatable using these new, Windows-native PowerShell cmdlets. To support these requirements, there is a new HLK test to verify if vendor products support the right commands and get them implemented in future revisions. Here are links to the various requirements:

• SATA: https://msdn.microsoft.com/en-us/library/windows/hardware/dn932747(v=vs.85).aspx
  • Section [If Implemented] Firmware Download & Activate
• SAS: https://msdn.microsoft.com/en-us/library/windows/hardware/dn932746(v=vs.85).aspx
  • Section: [If Implemented] Firmware Download & Activate
• NVMe: https://msdn.microsoft.com/en-us/library/windows/hardware/dn932708(v=vs.85).aspx
  • Sections: 5.7 and 5.8

PowerShell cmdlets

The two cmdlets added to Windows Server 2016 are:

• Get-StorageFirmwareInformation
• Update-StorageFirmware

The first cmdlet provides you with detailed information about the device’s capabilities, firmware images, and revisions. In this case, the machine only contains a single SATA SSD with 1 firmware slot. Here’s an example:

PS C:\> Get-PhysicalDisk | Get-StorageFirmwareInformation
SupportsUpdate        : True
NumberOfSlots         : 1
ActiveSlotNumber      : 0
SlotNumber            : {0}
IsSlotWritable        : {True}
FirmwareVersionInSlot : {J3E16101}
PS C:\>

Note: SAS devices will always report “SupportsUpdate” as “True”, since there is no way of explicitly querying the device for support of these commands.

The second cmdlet will allow the administrator to update the drive firmware with an image file. You should obtain this image file from the OEM or drive vendor directly.

The disk will first load the new firmware image to an internal staging area. While this happens, I/O typically continues. The image activates after download. During this time the disk will not be able to respond to I/O commands as an internal reset occurs. This means that no data will be served from this disk during the update. An application accessing data on this disk would have to wait for a response until the firmware update is completed. Here’s an example of the cmdlet in action:

PS C:\> $pd | Update-StorageFirmware -ImagePath C:\Firmware\J3E160@3.enc -SlotNumber 0
PS C:\> $pd | Get-StorageFirmwareInformation
SupportsUpdate        : True
NumberOfSlots         : 1
ActiveSlotNumber      : 0
SlotNumber            : {0}
IsSlotWritable        : {True}
FirmwareVersionInSlot : {J3E160@3}
PS C:\>

Since these cmdlets are usable through PowerShell, it is also possible to script their use.

Note: Drives typically do not complete I/O requests when they activate a new firmware image. How long a drive takes to activate depends on its design and the type of firmware you update. We have observed update times range from fewer than 5 seconds to more than 30 seconds.

This particular drive performed the firmware update within ~5.8 seconds, as shown here:

PS C:\> Measure-Command {$pd | Update-StorageFirmware -ImagePath C:\Firmware\J3E16101.enc -SlotNumber 0}
Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 5
Milliseconds      : 791
Ticks             : 57913910
TotalDays         : 6.70299884259259E-05
TotalHours        : 0.00160871972222222
TotalMinutes      : 0.0965231833333333
TotalSeconds      : 5.791391
TotalMilliseconds : 5791.391

FAQ

• Can I update firmware on my SAN through this mechanism?
  • No – SANs usually have their own utilities and interfaces for such maintenance operations. This new mechanism is for directly attached storage, such as SATA, SAS, or NVMe devices.
• Will this work on any storage device?
  • This will work on drives that implement the correct commands in their firmware. The Get-StorageFirmwareInformation cmdlet will show if a drive’s firmware indeed does support the correct commands (for SATA/NVMe) and the HLK test allows vendors and OEMs to test this behavior.
• From where do I get the firmware image?
  • You should obtain any firmware directly from your OEM or drive vendor and not download it from other parties.
• Will this work on clustered disks?
  • The cmdlets can perform their function on clustered disks as well, but keep in mind that no orchestration exists in TP4 to mitigate the I/O impact on running workloads. In general, it is best to perform disk firmware updates when there is no, or just a minimal workload on the underlying disks.
• What happens when the update fails?
  • The update could fail for various reasons, some of them are: 1) The drive doesn’t support the correct commands for Windows to update its firmware. In this case the new firmware image is never activated and the drive continues functioning with the old image. 2) The image cannot be downloaded to or applied to this drive (version mismatch, corrupt image, …). In this case the drive is expected to fail the activate command. Again, the old firmware image should continue to function.
  • If the drive does not respond after a firmware update, you are most likely hitting a bug in the drive firmware itself. This is why all firmware updates should first be tested in a lab environment before putting them in production.