1
00:00:00,740 --> 00:00:01,750
And as I mentioned,

2
00:00:01,750 --> 00:00:07,440
one of the two services we're concerned with here is Storage Migration Service.

3
00:00:07,440 --> 00:00:09,450
What is Storage Migration Service?

4
00:00:09,450 --> 00:00:09,640
Well,

5
00:00:09,640 --> 00:00:13,430
its main value proposition is it's a Windows Server technology

6
00:00:13,430 --> 00:00:16,850
that helps you rapidly migrate individual files,

7
00:00:16,850 --> 00:00:20,250
but principally file shares and their associated

8
00:00:20,250 --> 00:00:22,430
configurations from a source server,

9
00:00:22,430 --> 00:00:25,970
either to say a newer server that's running a more

10
00:00:25,970 --> 00:00:28,040
recent version of Windows Server.

11
00:00:28,040 --> 00:00:32,090
But there's also a path where storage migration ties in with Azure

12
00:00:32,090 --> 00:00:36,190
Migrate to migrate your file server entirely to Azure.

13
00:00:36,190 --> 00:00:40,300
Now we're going to get into the server migration big time in the next module.

14
00:00:40,300 --> 00:00:41,390
In this one,

15
00:00:41,390 --> 00:00:45,640
we're looking at a lighter weight scenario where you have an on‑premises

16
00:00:45,640 --> 00:00:48,930
file server that say is running Windows Server 2019,

17
00:00:48,930 --> 00:00:52,760
and now you have a Windows Server 2022 box that you want to

18
00:00:52,760 --> 00:00:57,440
take over those shares without interrupting your existing

19
00:00:57,440 --> 00:00:59,860
drive mappings and other dependencies,

20
00:00:59,860 --> 00:01:02,680
you don't want to interrupt your user experience,

21
00:01:02,680 --> 00:01:03,320
all right?

22
00:01:03,320 --> 00:01:06,380
Now the Storage Migration Service supports Windows,

23
00:01:06,380 --> 00:01:11,040
whether or not those machines are in failover clusters,

24
00:01:11,040 --> 00:01:12,790
as well as Linux, which, again,

25
00:01:12,790 --> 00:01:16,520
that never ceases to amaze me that Microsoft supports Linux

26
00:01:16,520 --> 00:01:18,660
and even has its own Linux distribution.

27
00:01:18,660 --> 00:01:22,500
It's a great time to be a Microsoft specialist for sure.

28
00:01:22,500 --> 00:01:25,360
You'll need a separate server called an Orchestrator server,

29
00:01:25,360 --> 00:01:28,650
and this performs things like the inventory process,

30
00:01:28,650 --> 00:01:32,410
exactly what are those file shares, how many files,

31
00:01:32,410 --> 00:01:34,800
how much storage are we talking about. Now,

32
00:01:34,800 --> 00:01:38,940
technically you can get away with using the source server as your Orchestrator,

33
00:01:38,940 --> 00:01:41,600
but if you're going to be doing this to any degree of scale,

34
00:01:41,600 --> 00:01:46,840
you'll want to set up a separate Windows Server Azure Orchestrator host.

35
00:01:46,840 --> 00:01:51,070
The UI, or the user interface front end, is actually Windows Admin Center.

36
00:01:51,070 --> 00:01:52,800
And that's good, because number one,

37
00:01:52,800 --> 00:01:56,450
Windows Admin Center features on both AZ‑800 and 801,

38
00:01:56,450 --> 00:02:00,340
so it's a tool you need to be familiar with at any rate.

39
00:02:00,340 --> 00:02:03,790
And number two, I like it because it's so universal.

40
00:02:03,790 --> 00:02:04,720
It runs in a browser,

41
00:02:04,720 --> 00:02:10,060
so as long as you can get to the WAC service running on a server,

42
00:02:10,060 --> 00:02:12,180
doesn't matter whether you're on Linux, Mac,

43
00:02:12,180 --> 00:02:14,260
or Windows, or even a mobile device.

44
00:02:14,260 --> 00:02:15,640
Pretty convenient.

45
00:02:15,640 --> 00:02:19,770
So, in summary, we're looking to steal the identity of the source machine.

46
00:02:19,770 --> 00:02:21,300
We may have an older,

47
00:02:21,300 --> 00:02:24,220
down‑level file server that we ultimately want to

48
00:02:24,220 --> 00:02:27,070
decommission. How can we with minimal muss,

49
00:02:27,070 --> 00:02:31,240
fuss, or greasy aftertaste, transfer not only those file shares,

50
00:02:31,240 --> 00:02:33,550
but also their security configuration.

51
00:02:33,550 --> 00:02:35,870
You might've put quite a bit of time, for instance,

52
00:02:35,870 --> 00:02:41,540
in discretionary access control lists and NTF permissions. You also may have

53
00:02:41,540 --> 00:02:45,470
local users and groups on the source server. Believe it or not,

54
00:02:45,470 --> 00:02:49,540
storage migration can handle all of that stuff as well.

55
00:02:49,540 --> 00:02:59,000
The goal is the new server hosting those file shares will be indistinguishable from a client standpoint from the source server.