1 00:00:00,640 --> 00:00:04,770 Let's take a look at an example topology I've created for us here. 2 00:00:04,770 --> 00:00:09,640 The deployment workflow for Azure File Sync Service involves creating an 3 00:00:09,640 --> 00:00:12,690 instance of what Microsoft calls the Storage Sync Service. 4 00:00:12,690 --> 00:00:16,150 Now, you might be fine with just one Storage Sync Service. 5 00:00:16,150 --> 00:00:19,780 This is the top level of the Azure File Sync object model. 6 00:00:19,780 --> 00:00:22,470 And within the single Storage Sync Service, 7 00:00:22,470 --> 00:00:25,000 you create what are called sync groups. 8 00:00:25,000 --> 00:00:26,640 And what a sync group is, 9 00:00:26,640 --> 00:00:30,310 its one and only one file share from a general purpose 10 00:00:30,310 --> 00:00:33,330 storage account in your Azure subscription mapped to one 11 00:00:33,330 --> 00:00:35,030 or more registered file servers. 12 00:00:35,030 --> 00:00:37,660 These are Windows servers that will be running a service, 13 00:00:37,660 --> 00:00:38,320 an agent, 14 00:00:38,320 --> 00:00:42,420 that links that machine to their sync group and supports that 15 00:00:42,420 --> 00:00:45,920 two‑way synchronization between the local file system and the 16 00:00:45,920 --> 00:00:47,630 file share in the sync group. 17 00:00:47,630 --> 00:00:50,780 Questions like now are you going to need to edit drive mappings, 18 00:00:50,780 --> 00:00:54,650 will this affect work folders, will this affect mapped network drives, 19 00:00:54,650 --> 00:00:55,540 these sorts of things? 20 00:00:55,540 --> 00:00:56,020 No. 21 00:00:56,020 --> 00:01:00,040 The Azure File Sync engineers were very sensitive in terms of they wanted 22 00:01:00,040 --> 00:01:03,810 Azure File Sync to help your IT staff and indirectly, 23 00:01:03,810 --> 00:01:04,880 of course, the users. 24 00:01:04,880 --> 00:01:09,080 But ultimately, they didn't want to impact the users' connectivity at all. 25 00:01:09,080 --> 00:01:13,210 So no drive mappings or anything like that will be disrupted at all. 26 00:01:13,210 --> 00:01:17,020 They will continue. Those users and applications locally will continue to 27 00:01:17,020 --> 00:01:20,090 access those files shares locally as they always do. 28 00:01:20,090 --> 00:01:23,700 It's just behind the scenes, we have this hybrid cloud stuff going on, 29 00:01:23,700 --> 00:01:27,280 this cloud synchronization and cloud tiering with Azure File Sync. 30 00:01:27,280 --> 00:01:29,550 Now to answer specific questions, well, 31 00:01:29,550 --> 00:01:33,400 what if we have a catastrophic failure or what if we need to take a file 32 00:01:33,400 --> 00:01:36,360 server down for maintenance and you're not currently using, 33 00:01:36,360 --> 00:01:40,280 say, Windows Server failover clustering to do scale out file server? 34 00:01:40,280 --> 00:01:43,170 What if my singleton file server goes down? 35 00:01:43,170 --> 00:01:45,760 I'm going to immediately cause a denial of service, aren't I? 36 00:01:45,760 --> 00:01:47,420 Well, yeah, in the short run, 37 00:01:47,420 --> 00:01:51,040 but that run is going to be much shorter with Azure File Sync because you 38 00:01:51,040 --> 00:01:55,790 literally can install the AFS agent on another machine in your domain and 39 00:01:55,790 --> 00:02:00,150 then recreate the shared folders from the appropriate sync groups that are 40 00:02:00,150 --> 00:02:01,820 running in your Storage Sync Service. 41 00:02:01,820 --> 00:02:02,580 Isn't that awesome? 42 00:02:02,580 --> 00:02:05,370 Another thing to consider is what if your file server 43 00:02:05,370 --> 00:02:07,140 is running short of storage space? 44 00:02:07,140 --> 00:02:10,040 That's a perpetual problem for systems administrators. 45 00:02:10,040 --> 00:02:10,450 Optionally, 46 00:02:10,450 --> 00:02:15,750 we have the ability to do cloud tiering where the users and applications will 47 00:02:15,750 --> 00:02:19,660 see files in file listings on those shared folders locally, 48 00:02:19,660 --> 00:02:23,070 but those resources may have been offloaded to the cloud. And at first 49 00:02:23,070 --> 00:02:27,120 access, the AFS agent will retrieve that resource, so there may be a 50 00:02:27,120 --> 00:02:29,860 little bit of latency depending upon the speed of your internet 51 00:02:29,860 --> 00:02:32,280 connection to retrieve that offloaded file. 52 00:02:32,280 --> 00:02:34,940 But it is there. It shows up in directory listings. 53 00:02:34,940 --> 00:02:37,830 It's just that you're immediately saving space on that 54 00:02:37,830 --> 00:02:39,640 local file server's file system. 55 00:02:39,640 --> 00:02:40,290 Lastly, 56 00:02:40,290 --> 00:02:43,610 if you're using distributed file system, particularly DFS 57 00:02:43,610 --> 00:02:47,200 replication to replicate file shares across sites in your 58 00:02:47,200 --> 00:02:51,040 organization, can you combine Azure File Sync and DFS? 59 00:02:51,040 --> 00:02:51,770 Yes, you can. 60 00:02:51,770 --> 00:02:55,310 Like I said, we're going to cover this in much more detail in the next module. 61 00:02:55,310 --> 00:02:58,170 One hazard though is, during the migration, you want to 62 00:02:58,170 --> 00:03:00,210 be careful not to use cloud tiering. 63 00:03:00,210 --> 00:03:03,190 That can cause some confusion and some problems between 64 00:03:03,190 --> 00:03:06,120 AFS on one hand and DFSR on the other. 65 00:03:06,120 --> 00:03:06,490 But again, 66 00:03:06,490 --> 00:03:16,000 we have to remember one of the guiding business propositions of AFS is to help businesses evolve or migrate past DFS.