WEBVTT

1
00:00:00.160 --> 00:00:02.480
<v Speaker 1>Welcome to the deep dive, where we take your source

2
00:00:02.520 --> 00:00:06.679
<v Speaker 1>material and uncover the most fascinating insights. So when you

3
00:00:06.679 --> 00:00:10.480
<v Speaker 1>hear the word server, what's the first image that pops

4
00:00:10.480 --> 00:00:11.080
<v Speaker 1>into your head.

5
00:00:11.199 --> 00:00:13.160
<v Speaker 2>Yeah, probably you know, a big humming box in a

6
00:00:13.240 --> 00:00:16.719
<v Speaker 2>data center somewhere, lots of blinking lights, tons of hardware,

7
00:00:16.800 --> 00:00:17.359
<v Speaker 2>that kind of thing.

8
00:00:17.399 --> 00:00:19.640
<v Speaker 1>Exactly that classic image. But what if we told you

9
00:00:19.640 --> 00:00:24.000
<v Speaker 1>that the real core of what makes a server well,

10
00:00:24.160 --> 00:00:27.480
<v Speaker 1>a server isn't really the box itself. It's actually all

11
00:00:27.519 --> 00:00:28.800
<v Speaker 1>about the software.

12
00:00:28.440 --> 00:00:31.719
<v Speaker 2>Running on it. It's a really fundamental shift in thinking,

13
00:00:31.760 --> 00:00:35.799
<v Speaker 2>isn't it, And it really underpins almost everything we do

14
00:00:35.840 --> 00:00:39.119
<v Speaker 2>in modern IT these days. Today we're going to dive

15
00:00:39.159 --> 00:00:42.119
<v Speaker 2>deep into Windows Server twenty sixteen. Well, look at its

16
00:00:42.159 --> 00:00:45.320
<v Speaker 2>core technologies, how it delivers robus services, make sure things

17
00:00:45.320 --> 00:00:48.560
<v Speaker 2>stay up and running, high availability, and how it really

18
00:00:48.640 --> 00:00:50.560
<v Speaker 2>embraces modern computing precisely.

19
00:00:50.920 --> 00:00:54.039
<v Speaker 1>So, whether you're maybe mapping out your next IT project

20
00:00:54.240 --> 00:00:56.600
<v Speaker 1>or prepping for a meeting, or maybe you're just curious

21
00:00:56.640 --> 00:00:59.479
<v Speaker 1>about what makes the digital world tick, we're here to

22
00:00:59.479 --> 00:00:59.759
<v Speaker 1>give you that.

23
00:01:00.600 --> 00:01:04.079
<v Speaker 2>Yeah, gets you those aha moments, you know, without drowning

24
00:01:04.120 --> 00:01:05.359
<v Speaker 2>you in technical jargon.

25
00:01:05.359 --> 00:01:08.879
<v Speaker 1>Exactly, So over the next few minutes, we'll unpack how

26
00:01:08.920 --> 00:01:11.719
<v Speaker 1>even simple hardware can become a powerhouse. We'll get into

27
00:01:11.760 --> 00:01:13.200
<v Speaker 1>some really clever storage tricks.

28
00:01:13.239 --> 00:01:15.799
<v Speaker 2>Oh yeah, storage spaces indeed, depth good stuff there.

29
00:01:15.840 --> 00:01:20.359
<v Speaker 1>Peek into virtualization and containers, and uncover some secrets to

30
00:01:20.439 --> 00:01:22.680
<v Speaker 1>keeping everything online pretty much all the time.

31
00:01:22.799 --> 00:01:23.519
<v Speaker 2>Sounds like a plan.

32
00:01:23.840 --> 00:01:26.239
<v Speaker 1>Okay, So let's tackle that server image head on. You

33
00:01:26.280 --> 00:01:29.480
<v Speaker 1>said it's less about the box, more the software the mindset.

34
00:01:29.519 --> 00:01:31.599
<v Speaker 1>Can you break that down a bit, because it really does.

35
00:01:31.480 --> 00:01:35.000
<v Speaker 2>Change things absolutely. That old idea of a server just

36
00:01:35.000 --> 00:01:38.879
<v Speaker 2>being beef hardware is well, it's kind of outdated. Now.

37
00:01:39.359 --> 00:01:42.799
<v Speaker 2>A computer becomes a server when you install software on

38
00:01:42.879 --> 00:01:45.560
<v Speaker 2>it that's built to provide network services.

39
00:01:45.159 --> 00:01:47.200
<v Speaker 1>So like rolls and features.

40
00:01:46.799 --> 00:01:50.640
<v Speaker 2>Exactly roles and features that serve clients. You could theoretically

41
00:01:50.799 --> 00:01:54.760
<v Speaker 2>take an inexpensive laptop, install the right software and boom,

42
00:01:54.760 --> 00:01:58.560
<v Speaker 2>it's a server for some specific task. And conversely, you

43
00:01:58.599 --> 00:02:01.400
<v Speaker 2>could have this absolute beast of a machine loaded with

44
00:02:01.480 --> 00:02:05.359
<v Speaker 2>processors in RAM. But if it's just running desktop apps

45
00:02:05.359 --> 00:02:09.520
<v Speaker 2>for one person, it's just a powerful workstation, right.

46
00:02:09.280 --> 00:02:12.000
<v Speaker 1>So the difference isn't just raw horsepower, it's the job

47
00:02:12.039 --> 00:02:15.039
<v Speaker 1>it's doing. The specialized functions. What kind of things does

48
00:02:15.080 --> 00:02:18.280
<v Speaker 1>Windows Server twenty sixteen do that, say, my Windows ten

49
00:02:18.360 --> 00:02:19.560
<v Speaker 1>machine just can't.

50
00:02:19.759 --> 00:02:23.360
<v Speaker 2>Ah, that's the key distinction. Windows Server is built from

51
00:02:23.400 --> 00:02:27.199
<v Speaker 2>the ground up for resilience, for scale, for running twenty

52
00:02:27.199 --> 00:02:29.479
<v Speaker 2>four to seven. It has things like built in fault

53
00:02:29.560 --> 00:02:32.599
<v Speaker 2>tolerance features like ray.

54
00:02:32.439 --> 00:02:36.719
<v Speaker 1>Five volumes okay, redundant array of independent disks level five.

55
00:02:36.560 --> 00:02:39.800
<v Speaker 2>Right, plus sophisticated load balancing, clustering, stuff you just don't

56
00:02:39.840 --> 00:02:41.960
<v Speaker 2>find in a standard desktop OS like Windows ten.

57
00:02:42.520 --> 00:02:44.840
<v Speaker 1>And the hardware support is different too, lassively different.

58
00:02:45.000 --> 00:02:47.280
<v Speaker 2>Windows Server twenty sixteen can handle I think up to

59
00:02:47.400 --> 00:02:51.680
<v Speaker 2>sixty four processors compared to just two for Windows ten

60
00:02:51.719 --> 00:02:54.240
<v Speaker 2>pro wow and users. Windows ten might limit you to

61
00:02:54.240 --> 00:02:57.439
<v Speaker 2>maybe twenty network connections. Windows Server Standard or data center.

62
00:02:57.479 --> 00:03:00.000
<v Speaker 2>It's basically unlimited by the OS itself. You're limited by

63
00:03:00.120 --> 00:03:02.639
<v Speaker 2>your licenses and how much the hardware can handle. Is

64
00:03:02.680 --> 00:03:04.680
<v Speaker 2>designed for hundreds of thousands of users.

65
00:03:04.919 --> 00:03:07.520
<v Speaker 1>Okay, that pains a really clear picture. It's built for

66
00:03:07.639 --> 00:03:14.240
<v Speaker 1>mission critical stuff. Now let's talk storage. That's always huge, right, bottlenecks, failures.

67
00:03:15.159 --> 00:03:18.960
<v Speaker 1>How does Windows Server twenty sixteen handle discs smartly?

68
00:03:19.240 --> 00:03:22.199
<v Speaker 2>Yes? Storage tech has come a long way. Storage spaces

69
00:03:22.240 --> 00:03:24.840
<v Speaker 2>in Windows Server twenty sixteen is a great example. It

70
00:03:24.960 --> 00:03:30.960
<v Speaker 2>lets you take a bunch of different physical drives USB, SATA, SaaS, internal, external,

71
00:03:31.080 --> 00:03:34.479
<v Speaker 2>even different sizes, and pool them together, cool them. Yeah,

72
00:03:34.560 --> 00:03:37.080
<v Speaker 2>create a storage pool, and then you carve out virtual

73
00:03:37.120 --> 00:03:40.520
<v Speaker 2>discs from that pool. These virtual discs can be flexible,

74
00:03:40.680 --> 00:03:44.639
<v Speaker 2>fault tolerant, and you don't necessarily need those expensive hardware

75
00:03:44.680 --> 00:03:45.719
<v Speaker 2>rate controllers anymore.

76
00:03:45.800 --> 00:03:48.800
<v Speaker 1>That flexibility sounds amazing, especially if you've got mixed hardware

77
00:03:48.840 --> 00:03:52.039
<v Speaker 1>lying around and you mentioned something about capacity planning. Thin

78
00:03:52.120 --> 00:03:53.639
<v Speaker 1>provisioning that sounds interesting.

79
00:03:53.759 --> 00:03:56.120
<v Speaker 2>Oh, thin provision is brilliant. I mean you can create

80
00:03:56.120 --> 00:03:58.759
<v Speaker 2>a virtual disc and tell the system, okay, this volume

81
00:03:58.759 --> 00:04:01.159
<v Speaker 2>can grow up to say t terabytes, right, But the

82
00:04:01.159 --> 00:04:03.840
<v Speaker 2>system doesn't actually grab all ten terabytes of physical disk

83
00:04:03.840 --> 00:04:06.800
<v Speaker 2>space right away. It only allocates space from the pool

84
00:04:06.960 --> 00:04:08.960
<v Speaker 2>as data is actually written to the volume.

85
00:04:09.199 --> 00:04:12.560
<v Speaker 1>Ah. So you provision big, but you only pay for

86
00:04:12.879 --> 00:04:15.360
<v Speaker 1>or use the physical space you need. Now that must

87
00:04:15.360 --> 00:04:17.319
<v Speaker 1>be huge for managing costs and scaling.

88
00:04:17.480 --> 00:04:22.920
<v Speaker 2>It absolutely is huge for optimizing resources, deferring hardware purchases,

89
00:04:23.480 --> 00:04:27.240
<v Speaker 2>and for resilience within storage spaces. You've got good options.

90
00:04:27.839 --> 00:04:29.160
<v Speaker 2>Mirror space is like grade one.

91
00:04:29.240 --> 00:04:31.160
<v Speaker 1>Okay, data is duplicated, right.

92
00:04:31.480 --> 00:04:33.879
<v Speaker 2>A two way mirror writes data to two discs, so

93
00:04:33.959 --> 00:04:36.720
<v Speaker 2>it can survive one disc failing needs at least two

94
00:04:36.759 --> 00:04:40.639
<v Speaker 2>physical discs for more protection. A three way mirror writs

95
00:04:40.680 --> 00:04:41.319
<v Speaker 2>to three.

96
00:04:41.120 --> 00:04:44.079
<v Speaker 1>Discs, needs five discs total for that though.

97
00:04:43.920 --> 00:04:46.040
<v Speaker 2>It needs five physical discs. Yeah, but it can survive

98
00:04:46.120 --> 00:04:49.079
<v Speaker 2>two disc failures. Mirroring is generally recommended for pretty much

99
00:04:49.079 --> 00:04:50.759
<v Speaker 2>any storage that needs resilience in good.

100
00:04:50.600 --> 00:04:54.120
<v Speaker 1>Performance okay, so it's top performance, top aliability with mirroring.

101
00:04:54.279 --> 00:04:56.600
<v Speaker 1>What if you need to be more space efficient, maybe

102
00:04:56.639 --> 00:04:58.120
<v Speaker 1>for backups or archives.

103
00:04:58.199 --> 00:05:00.399
<v Speaker 2>That's where parity space comes in. It's more like five

104
00:05:00.560 --> 00:05:03.680
<v Speaker 2>or RAD six. A single parity space stripes data and

105
00:05:03.720 --> 00:05:07.000
<v Speaker 2>parity info across discs. These at least three discs can

106
00:05:07.040 --> 00:05:07.680
<v Speaker 2>handle one.

107
00:05:07.519 --> 00:05:09.120
<v Speaker 1>Failure, and dual parody.

108
00:05:09.319 --> 00:05:12.519
<v Speaker 2>Dual parody uses two sets of parity info, needs at

109
00:05:12.600 --> 00:05:16.120
<v Speaker 2>least seven discs and can survive two failures. It's much

110
00:05:16.120 --> 00:05:17.959
<v Speaker 2>more space efficient than mirroring.

111
00:05:17.639 --> 00:05:19.240
<v Speaker 1>But there's always a butt, but.

112
00:05:19.199 --> 00:05:22.399
<v Speaker 2>The right performance is generally lower calculating that parity takes

113
00:05:22.439 --> 00:05:25.839
<v Speaker 2>some overhead, so parity spaces are usually better for things

114
00:05:25.879 --> 00:05:30.759
<v Speaker 2>like archival storage backups. Data that isn't constantly being written

115
00:05:30.759 --> 00:05:31.600
<v Speaker 2>to at high speed?

116
00:05:31.720 --> 00:05:36.600
<v Speaker 1>Got it? Balancing acts between space performance and resilience. Okay,

117
00:05:36.600 --> 00:05:40.079
<v Speaker 1>so we've organized the disks, what about actually saving space

118
00:05:40.120 --> 00:05:43.319
<v Speaker 1>on them. Data d duplication sounds almost like magic.

119
00:05:44.199 --> 00:05:47.560
<v Speaker 2>It does seem like magic sometimes. Data d duplication or

120
00:05:47.680 --> 00:05:51.199
<v Speaker 2>d DEP is seriously impressive tech. It uses a combination

121
00:05:51.279 --> 00:05:53.439
<v Speaker 2>of compression and finding duplicate data.

122
00:05:53.199 --> 00:05:55.920
<v Speaker 1>Blocks blocks, not just whole five right blocks.

123
00:05:56.160 --> 00:05:58.279
<v Speaker 2>So imagine you have ten copies of almost the same

124
00:05:58.319 --> 00:06:01.959
<v Speaker 2>PowerPoint presentation, maybe just the title slide changed, or lots

125
00:06:02.000 --> 00:06:05.560
<v Speaker 2>of virtual machine files that share common OS components. DTA

126
00:06:05.920 --> 00:06:07.800
<v Speaker 2>finds those identical blocks.

127
00:06:07.560 --> 00:06:09.839
<v Speaker 1>Of data and just stores one copy exactly.

128
00:06:10.040 --> 00:06:12.519
<v Speaker 2>It stores one unique copy of the block and replaces

129
00:06:12.600 --> 00:06:15.480
<v Speaker 2>all the other instances with tiny pointers back to that

130
00:06:15.560 --> 00:06:16.279
<v Speaker 2>single copy.

131
00:06:16.399 --> 00:06:19.720
<v Speaker 1>So all that redundant data just kind of evaporates, leaving

132
00:06:20.000 --> 00:06:22.759
<v Speaker 1>one real copy. What kind of savings are we talking

133
00:06:23.759 --> 00:06:24.759
<v Speaker 1>and any catches?

134
00:06:24.839 --> 00:06:28.360
<v Speaker 2>The savings can be really dramatic for things like user documents,

135
00:06:28.480 --> 00:06:32.839
<v Speaker 2>software install shares, VHD libraries. You often see fifty percent

136
00:06:32.839 --> 00:06:35.639
<v Speaker 2>to even ninety percent space savings. It's pretty common.

137
00:06:35.680 --> 00:06:36.120
<v Speaker 1>Wow.

138
00:06:36.319 --> 00:06:38.879
<v Speaker 2>But yeah, there are limitations. It doesn't work well or

139
00:06:38.920 --> 00:06:42.160
<v Speaker 2>at all on encrypted files or on very small files

140
00:06:42.160 --> 00:06:45.959
<v Speaker 2>generally under thirty two KP okay, And you need to

141
00:06:46.040 --> 00:06:48.040
<v Speaker 2>keep some free space on the volume for it to

142
00:06:48.079 --> 00:06:52.279
<v Speaker 2>work efficiently, usually at least ten percent. Also a key

143
00:06:52.319 --> 00:06:55.600
<v Speaker 2>point for twenty sixteen, it wasn't supported on cluster shared

144
00:06:55.680 --> 00:06:58.000
<v Speaker 2>volumes csvs for active workloads back then.

145
00:06:58.279 --> 00:07:01.600
<v Speaker 1>Good caveats to remember. Okay, storage is flexible efficient, But

146
00:07:01.639 --> 00:07:04.319
<v Speaker 1>what about the big like a whole server dying or

147
00:07:04.360 --> 00:07:06.759
<v Speaker 1>even a whole site going offline. That's where storage replica

148
00:07:06.759 --> 00:07:07.040
<v Speaker 1>comes in.

149
00:07:07.079 --> 00:07:10.639
<v Speaker 2>I assume absolutely. Storage Replica is your lifeline for disaster recovery,

150
00:07:10.639 --> 00:07:14.199
<v Speaker 2>for business continuity. It lets you replicate entire volumes between

151
00:07:14.199 --> 00:07:16.319
<v Speaker 2>servers or even between entire clusters.

152
00:07:16.360 --> 00:07:19.199
<v Speaker 1>Replica like keep an exact copy somewhere else precisely.

153
00:07:19.240 --> 00:07:21.639
<v Speaker 2>And the big choice here is how you replicate synchronous

154
00:07:21.720 --> 00:07:22.480
<v Speaker 2>or asynchronous?

155
00:07:22.720 --> 00:07:24.000
<v Speaker 1>Okay, what's the difference?

156
00:07:24.240 --> 00:07:27.879
<v Speaker 2>Synchronous replication is this super safe option. When your application

157
00:07:27.920 --> 00:07:31.720
<v Speaker 2>writes data, the system waits until that data is successfully

158
00:07:31.720 --> 00:07:34.439
<v Speaker 2>written to both the main site and the replica site

159
00:07:34.639 --> 00:07:38.040
<v Speaker 2>before it tells the application okay done, ah.

160
00:07:37.800 --> 00:07:41.399
<v Speaker 1>So zero data loss guaranteed, even if the main site

161
00:07:41.480 --> 00:07:43.040
<v Speaker 1>instantly disappears.

162
00:07:42.680 --> 00:07:47.240
<v Speaker 2>Exactly zero data loss guarantee, But it needs a really fast,

163
00:07:47.480 --> 00:07:51.480
<v Speaker 2>low latency network connection between the sites because that wait

164
00:07:51.639 --> 00:07:55.079
<v Speaker 2>time adds latencyed every single right operation.

165
00:07:54.879 --> 00:07:57.240
<v Speaker 1>Right, physics gets in the way. So what's the alternative

166
00:07:57.279 --> 00:08:00.279
<v Speaker 1>if your sites are far apart or the network isn't super.

167
00:08:00.120 --> 00:08:04.279
<v Speaker 2>Fast, that's asynchronous replication. With async the right happens on

168
00:08:04.319 --> 00:08:07.360
<v Speaker 2>the source. First, the system tells the app okay done.

169
00:08:07.560 --> 00:08:09.560
<v Speaker 2>Then it sends the data over to the replica site.

170
00:08:09.680 --> 00:08:12.319
<v Speaker 1>So faster for the application, but there's a small window.

171
00:08:12.480 --> 00:08:15.199
<v Speaker 2>There's a small potential for data loss. If the source

172
00:08:15.240 --> 00:08:17.759
<v Speaker 2>fails suddenly before the data makes it to the replica,

173
00:08:18.120 --> 00:08:20.639
<v Speaker 2>that last little bit might be lost. But it works

174
00:08:20.680 --> 00:08:23.120
<v Speaker 2>great over longer distances, higher latency networks.

175
00:08:23.399 --> 00:08:27.759
<v Speaker 1>So you trade that tiny risk for geographical flexibility. Makes sense.

176
00:08:28.240 --> 00:08:31.000
<v Speaker 1>It's about choosing the right tool for the job based

177
00:08:31.040 --> 00:08:33.679
<v Speaker 1>on your recovery needs and network exactly right.

178
00:08:33.960 --> 00:08:35.320
<v Speaker 2>It gives you critical options.

179
00:08:35.399 --> 00:08:38.879
<v Speaker 1>Okay, we've got solid storage foundations. Now let's move up

180
00:08:38.879 --> 00:08:42.720
<v Speaker 1>a layer into the virtual world hyper V. That's Windows

181
00:08:42.720 --> 00:08:46.120
<v Speaker 1>servers built in Hypervisor right the heart of its virtualization.

182
00:08:46.279 --> 00:08:48.639
<v Speaker 2>Ye, piper V is a server role. You install it

183
00:08:48.679 --> 00:08:51.960
<v Speaker 2>basically creates this software layer that mimics hardware, lets you

184
00:08:52.039 --> 00:08:54.679
<v Speaker 2>run multiple operating systems. We call them guest os is

185
00:08:55.000 --> 00:08:58.320
<v Speaker 2>all running isolator from each other on just one physical machine,

186
00:08:58.440 --> 00:08:58.840
<v Speaker 2>the host.

187
00:08:58.960 --> 00:09:01.480
<v Speaker 1>It's like having a whole rack of servers condensed into

188
00:09:01.519 --> 00:09:02.039
<v Speaker 1>one box.

189
00:09:02.159 --> 00:09:06.759
<v Speaker 2>Pretty much, massive boost in hardware utilization, simplifies management, speeds

190
00:09:06.840 --> 00:09:09.679
<v Speaker 2>up deployment. It's fundamental to modern data centers.

191
00:09:09.519 --> 00:09:13.000
<v Speaker 1>And these virtual machines. They need virtual hard drives vhds.

192
00:09:13.120 --> 00:09:14.200
<v Speaker 1>What are the options there?

193
00:09:14.639 --> 00:09:18.159
<v Speaker 2>Mainly see three types of virtual discs. Fixed sized discs

194
00:09:18.200 --> 00:09:20.200
<v Speaker 2>are kind of the old school way. You create one

195
00:09:20.240 --> 00:09:23.879
<v Speaker 2>hundred GMBVHD, it immediately takes up one hundred gigabe on

196
00:09:23.919 --> 00:09:25.679
<v Speaker 2>your host's storage.

197
00:09:25.200 --> 00:09:26.559
<v Speaker 1>Even if it's empty inside.

198
00:09:26.679 --> 00:09:30.399
<v Speaker 2>Even if it's empty, the benefit is slightly better performance sometimes,

199
00:09:30.639 --> 00:09:33.600
<v Speaker 2>especially for really disc heavy apps, because the system doesn't

200
00:09:33.639 --> 00:09:35.120
<v Speaker 2>have to resize the file on the fly.

201
00:09:35.519 --> 00:09:37.440
<v Speaker 1>Okay, what's more common.

202
00:09:37.200 --> 00:09:41.000
<v Speaker 2>Now dynamically expanding discs. These are much more flexible. You

203
00:09:41.000 --> 00:09:43.519
<v Speaker 2>still set a maximum size, say one hundred gigaby, but

204
00:09:43.600 --> 00:09:47.279
<v Speaker 2>the actual VHD file on the host starts tiny and

205
00:09:47.360 --> 00:09:49.240
<v Speaker 2>only grows as you add data inside the.

206
00:09:49.279 --> 00:09:54.759
<v Speaker 1>Vm AH like thin provisioning for VHDS saves host disk space.

207
00:09:54.639 --> 00:09:57.559
<v Speaker 2>Exactly great choice for most vms unless you have extreme

208
00:09:57.600 --> 00:10:01.200
<v Speaker 2>disc io needs, and then there's a special care pass

209
00:10:01.279 --> 00:10:04.320
<v Speaker 2>through discs pass through. Yeah, this isn't actually a virtual

210
00:10:04.360 --> 00:10:06.519
<v Speaker 2>disc file. You take a physical disc attached to the host,

211
00:10:06.759 --> 00:10:08.720
<v Speaker 2>get it offline in the host OS, and then you

212
00:10:08.759 --> 00:10:11.480
<v Speaker 2>attach that entire physical disc directly to a VM. The

213
00:10:11.559 --> 00:10:12.720
<v Speaker 2>VM gets raw access.

214
00:10:13.200 --> 00:10:14.000
<v Speaker 1>Why would you do that?

215
00:10:14.080 --> 00:10:16.000
<v Speaker 2>Maybe you have data already on that physical disc you

216
00:10:16.039 --> 00:10:18.960
<v Speaker 2>want the VM to access directly, or some very specific

217
00:10:19.000 --> 00:10:21.639
<v Speaker 2>performance scenario. It bypasses the virtual disc layer.

218
00:10:22.000 --> 00:10:26.440
<v Speaker 1>Interesting niche case, and the file formats VHD versus VHDX right.

219
00:10:26.759 --> 00:10:29.600
<v Speaker 2>VHD is the older format, limited to two terabytes per

220
00:10:29.679 --> 00:10:34.120
<v Speaker 2>virtual disc. VHDX is the newer format introduced later. It

221
00:10:34.159 --> 00:10:37.120
<v Speaker 2>supports much larger discs up to sixty four carabytes, has

222
00:10:37.159 --> 00:10:41.159
<v Speaker 2>better performance, and includes features like resilience against corruption if

223
00:10:41.159 --> 00:10:43.799
<v Speaker 2>there's a power failure during a rite. Generally you want

224
00:10:43.799 --> 00:10:45.759
<v Speaker 2>to use VHDX for new vms.

225
00:10:45.559 --> 00:10:49.639
<v Speaker 1>Could tip okay, VM's virtual discs. How do they talk

226
00:10:49.679 --> 00:10:53.200
<v Speaker 1>to each other and to the outside world Virtual networks YEP.

227
00:10:53.120 --> 00:10:56.480
<v Speaker 2>Through virtual networks managed by virtual switches. There are three

228
00:10:56.519 --> 00:10:58.879
<v Speaker 2>main types of virtual switches you can create in hyper

229
00:10:59.000 --> 00:11:02.559
<v Speaker 2>v Okay, an external virtual switch links your VMS to

230
00:11:02.600 --> 00:11:05.480
<v Speaker 2>a physical network adapter and I see on the host.

231
00:11:05.960 --> 00:11:08.799
<v Speaker 2>This lets the vms talk to the physical network, the Internet,

232
00:11:08.960 --> 00:11:12.399
<v Speaker 2>other physical machines, and the host itself. It's the most common.

233
00:11:12.159 --> 00:11:14.480
<v Speaker 1>Type, makes sense, connects virtual to physical What.

234
00:11:14.440 --> 00:11:17.720
<v Speaker 2>Else an internal virtual switch. This creates a network that

235
00:11:17.799 --> 00:11:20.080
<v Speaker 2>only the vms on that host and the host itself

236
00:11:20.120 --> 00:11:22.120
<v Speaker 2>can use. They can all talk to each other, but

237
00:11:22.159 --> 00:11:24.440
<v Speaker 2>they cannot reach the physical network beyond the host.

238
00:11:24.519 --> 00:11:27.000
<v Speaker 1>Ah isolated, but the host is included right.

239
00:11:27.440 --> 00:11:32.080
<v Speaker 2>And finally, a private virtual switch. This is total isolation.

240
00:11:32.720 --> 00:11:35.399
<v Speaker 2>Only the vms connected to that private switch can talk

241
00:11:35.440 --> 00:11:37.840
<v Speaker 2>to each other. They can't even talk to the host machine,

242
00:11:37.919 --> 00:11:39.320
<v Speaker 2>let alone the physical network.

243
00:11:39.399 --> 00:11:42.919
<v Speaker 1>Okay, useful for sandboxing or specific tiered applications, maybe.

244
00:11:42.840 --> 00:11:45.799
<v Speaker 2>Exactly, security boundaries, testing labs, things like that.

245
00:11:46.240 --> 00:11:49.960
<v Speaker 1>Now within these virtual networks, especially the external ones, are

246
00:11:49.960 --> 00:11:53.159
<v Speaker 1>there more advanced controls? How do you manage traffic or

247
00:11:53.240 --> 00:11:55.120
<v Speaker 1>security more granularly? Oh?

248
00:11:55.200 --> 00:11:58.639
<v Speaker 2>Yes, lots of advanced features. Volume IDs. For example, just

249
00:11:58.679 --> 00:12:01.240
<v Speaker 2>like on physical switches, you can sign vland tags to

250
00:12:01.440 --> 00:12:04.840
<v Speaker 2>virtual network adapters. This lets you segment traffic from different

251
00:12:04.919 --> 00:12:08.320
<v Speaker 2>vms onto different logical networks, even if they're all connected

252
00:12:08.320 --> 00:12:10.159
<v Speaker 2>to the same external virtual switch.

253
00:12:10.360 --> 00:12:15.200
<v Speaker 1>So better organization and security without needing tons of physical NICs. Smart.

254
00:12:15.240 --> 00:12:17.679
<v Speaker 1>What about MAC address spoofing That sounds bad?

255
00:12:17.799 --> 00:12:20.960
<v Speaker 2>Huh? Usually, yes, you don't want machines just pretending to

256
00:12:20.960 --> 00:12:24.399
<v Speaker 2>be other machines, But hyper v lets you enable MAC

257
00:12:24.440 --> 00:12:27.840
<v Speaker 2>scoofing on a VM's virtual NIC for specific reasons like what.

258
00:12:28.080 --> 00:12:31.159
<v Speaker 2>Certain types of network clustering inside the vms, like network

259
00:12:31.200 --> 00:12:34.720
<v Speaker 2>load balancing NLP, sometimes require the VM to be able

260
00:12:34.759 --> 00:12:37.679
<v Speaker 2>to use a shared or virtual MC address, so you

261
00:12:37.759 --> 00:12:40.720
<v Speaker 2>enable spoofing just for those specific vms that need it.

262
00:12:40.879 --> 00:12:45.120
<v Speaker 1>AH unnecessary evil in some cases, Okay. Any other key

263
00:12:45.200 --> 00:12:47.360
<v Speaker 1>security features in virtual networking.

264
00:12:47.080 --> 00:12:49.200
<v Speaker 2>DHDP guard is a big one. You really want this

265
00:12:49.320 --> 00:12:52.080
<v Speaker 2>enabled on pretty much all your vms do. It prevents

266
00:12:52.120 --> 00:12:54.519
<v Speaker 2>that VM from acting like a DHCP server, you know,

267
00:12:54.559 --> 00:12:57.600
<v Speaker 2>the service that hands out IP addresses. A rogue DHGP

268
00:12:57.759 --> 00:13:00.279
<v Speaker 2>server may be accidentally started by a user in side

269
00:13:00.320 --> 00:13:04.159
<v Speaker 2>of VM, or even maliciously can cause chaos on your network.

270
00:13:03.919 --> 00:13:07.559
<v Speaker 1>Right handing out bad IP addresses, disrupting everyone exactly.

271
00:13:07.600 --> 00:13:11.720
<v Speaker 2>So DHP guard blocks the outgoing DXCP server messages from

272
00:13:11.720 --> 00:13:14.480
<v Speaker 2>that VM. You only leave it disabled on your actual

273
00:13:14.559 --> 00:13:16.000
<v Speaker 2>authorized DHGP server.

274
00:13:15.879 --> 00:13:18.360
<v Speaker 1>VMS critical security setting them and you can even do

275
00:13:18.480 --> 00:13:22.159
<v Speaker 1>NIC teaming inside of VM, like team up virtual NICs.

276
00:13:22.200 --> 00:13:25.080
<v Speaker 2>You can even if the host server already has physical

277
00:13:25.159 --> 00:13:28.759
<v Speaker 2>NICs teamed, you can create another team inside the VM.

278
00:13:29.200 --> 00:13:33.240
<v Speaker 2>Using multiple virtual NICs connected to the same switch gives

279
00:13:33.279 --> 00:13:37.399
<v Speaker 2>you redundancy or potentially more bandwidth within that specific Virtual

280
00:13:37.440 --> 00:13:38.639
<v Speaker 2>machines operating system.

281
00:13:38.799 --> 00:13:43.080
<v Speaker 1>Wow. Layers upon layers of flexibility and resilience. Speaking of resilience,

282
00:13:43.320 --> 00:13:48.279
<v Speaker 1>moving VMS around without downtime live migration that still sounds

283
00:13:48.279 --> 00:13:48.919
<v Speaker 1>like magic to me.

284
00:13:49.159 --> 00:13:51.120
<v Speaker 2>It really is one of the coolest things hypervw does.

285
00:13:51.759 --> 00:13:55.919
<v Speaker 2>Live migration lets you move a running virtual machine, operating system, applications,

286
00:13:56.000 --> 00:13:58.799
<v Speaker 2>memory state everything from one hyper v host server to

287
00:13:58.879 --> 00:14:02.279
<v Speaker 2>another without any interruption to the service or the connected users.

288
00:14:02.399 --> 00:14:05.000
<v Speaker 1>Seriously, no downtime at all, zero.

289
00:14:04.759 --> 00:14:08.600
<v Speaker 2>Perceived downtime for the end user. If everything is configured correctly.

290
00:14:09.039 --> 00:14:11.320
<v Speaker 2>You can use to drain a host for maintenance balance

291
00:14:11.399 --> 00:14:15.639
<v Speaker 2>workloads across hosts. It's incredibly powerful for keeping things running smoothly.

292
00:14:15.720 --> 00:14:18.440
<v Speaker 1>That's amazing for infrastructure management. And you can move just

293
00:14:18.480 --> 00:14:20.960
<v Speaker 1>the storage too. Without moving the whole VM.

294
00:14:21.120 --> 00:14:24.159
<v Speaker 2>Yep, that's storage migration. You can move the VHD files

295
00:14:24.159 --> 00:14:27.960
<v Speaker 2>of running VM from one storage location, say one lun

296
00:14:28.080 --> 00:14:31.320
<v Speaker 2>or share, to another without interrupting the VM, and without

297
00:14:31.320 --> 00:14:32.759
<v Speaker 2>moving it to a different host server.

298
00:14:33.039 --> 00:14:36.080
<v Speaker 1>Useful for storage maintenance or moving to faster discs.

299
00:14:36.120 --> 00:14:39.799
<v Speaker 2>I guess exactly, rebalanced storage upgrade arrays migrate off a

300
00:14:40.000 --> 00:14:42.200
<v Speaker 2>hardware all while the VM keeps running.

301
00:14:42.440 --> 00:14:45.960
<v Speaker 1>Now, what about those little glitches like a temporary network

302
00:14:46.039 --> 00:14:49.360
<v Speaker 1>hiccup to the storage. Does the VM just crash? I

303
00:14:49.399 --> 00:14:52.480
<v Speaker 1>heard twenty sixteen improve this with VM resiliency.

304
00:14:52.720 --> 00:14:56.039
<v Speaker 2>It did make a significant improvement there. Before, if a

305
00:14:56.039 --> 00:14:59.240
<v Speaker 2>clustered VM briefly lost connection to its storage, it might

306
00:14:59.279 --> 00:15:02.879
<v Speaker 2>just fail over, causing a small outage. In Windows Server

307
00:15:02.960 --> 00:15:07.279
<v Speaker 2>twenty sixteen, especially with vms stored on cluster shared volumes csvs,

308
00:15:07.639 --> 00:15:10.480
<v Speaker 2>things got smarter. Oh, so, if a VM loses access

309
00:15:10.519 --> 00:15:13.480
<v Speaker 2>to its storage, instead of immediately crashing or failing over,

310
00:15:13.879 --> 00:15:16.440
<v Speaker 2>it might enter a temporary pause critical state. It just

311
00:15:17.039 --> 00:15:20.799
<v Speaker 2>waits for how long, potentially up to thirty minutes. If

312
00:15:20.799 --> 00:15:23.399
<v Speaker 2>the storage connection comes back within that time, maybe it

313
00:15:23.440 --> 00:15:26.159
<v Speaker 2>was just a network leitch, a switch rebooting the VM

314
00:15:26.360 --> 00:15:28.559
<v Speaker 2>automatically resumes right where it left off.

315
00:15:28.639 --> 00:15:32.440
<v Speaker 1>No failover, no reboot, just resumes, just resumes.

316
00:15:33.080 --> 00:15:36.000
<v Speaker 2>It turns a potential outage into just a temporary pause,

317
00:15:36.120 --> 00:15:39.559
<v Speaker 2>often unnoticed by users. It's a huge wind for stability,

318
00:15:39.879 --> 00:15:44.080
<v Speaker 2>especially in complex environments where transient storage issues can happen.

319
00:15:44.120 --> 00:15:48.960
<v Speaker 1>That's incredibly practical. Okay, shifting focus slightly to keeping services

320
00:15:49.000 --> 00:15:53.600
<v Speaker 1>highly available, not just individual VMS Network load balancing LB.

321
00:15:53.759 --> 00:15:54.440
<v Speaker 1>What's its role?

322
00:15:54.960 --> 00:15:58.279
<v Speaker 2>NLB is great for scaling out applications that are mostly stateless,

323
00:15:58.440 --> 00:16:00.799
<v Speaker 2>meaning they don't need to remember a complot details about

324
00:16:00.799 --> 00:16:04.159
<v Speaker 2>each user's session from one request to the next. Think

325
00:16:04.240 --> 00:16:07.840
<v Speaker 2>web servers serving stack content or maybe media streaming servers.

326
00:16:07.879 --> 00:16:08.519
<v Speaker 1>How does it work.

327
00:16:08.639 --> 00:16:11.759
<v Speaker 2>You set up multiple servers nodes running the same application.

328
00:16:12.039 --> 00:16:14.759
<v Speaker 2>LB presents a single virtual IP address to the clients

329
00:16:15.120 --> 00:16:17.759
<v Speaker 2>when requests come in, and LB distributes them across the

330
00:16:17.759 --> 00:16:20.320
<v Speaker 2>active nodes in the cluster. If one node fails, and

331
00:16:20.399 --> 00:16:22.000
<v Speaker 2>I'll be just stop sending traffic to it.

332
00:16:22.080 --> 00:16:25.200
<v Speaker 1>So more capacity and some basic fault tolerance for those

333
00:16:25.240 --> 00:16:25.519
<v Speaker 1>kinds of.

334
00:16:25.519 --> 00:16:28.559
<v Speaker 2>Apps exactly good for scaling out, but for applications that

335
00:16:28.600 --> 00:16:32.399
<v Speaker 2>are stateful or need true automatic failover of the service itself.

336
00:16:32.679 --> 00:16:34.360
<v Speaker 2>You need something more robust.

337
00:16:34.039 --> 00:16:36.279
<v Speaker 1>Which brings us to failover clusters.

338
00:16:36.679 --> 00:16:40.879
<v Speaker 2>Right. Failover clustering is the heavyweight champion of high availability

339
00:16:41.120 --> 00:16:45.039
<v Speaker 2>in the Windows world. You typically have two or more

340
00:16:45.120 --> 00:16:48.519
<v Speaker 2>servers nodes connected to some form of shared storage.

341
00:16:48.799 --> 00:16:50.440
<v Speaker 1>Shared storage is key here.

342
00:16:50.240 --> 00:16:53.639
<v Speaker 2>Absolutely the application data, the configuration, maybe the VM files.

343
00:16:53.639 --> 00:16:56.240
<v Speaker 2>If it's a hyperv cluster, it all is on storage

344
00:16:56.279 --> 00:16:59.320
<v Speaker 2>accessible by all nodes. Only one node is active for

345
00:16:59.360 --> 00:17:02.639
<v Speaker 2>a given cluster roll at a time. If that active node.

346
00:17:02.480 --> 00:17:05.279
<v Speaker 1>Fails, another node takes over exactly.

347
00:17:04.880 --> 00:17:08.480
<v Speaker 2>The cluster service detects the failure, brings the application resources

348
00:17:08.480 --> 00:17:12.240
<v Speaker 2>online on a passive node, which then becomes active. Clients

349
00:17:12.240 --> 00:17:15.160
<v Speaker 2>connect using a cluster name or IP address which follows

350
00:17:15.160 --> 00:17:18.160
<v Speaker 2>the active node, so the transition is often seamless or

351
00:17:18.319 --> 00:17:19.160
<v Speaker 2>very brief.

352
00:17:19.039 --> 00:17:20.920
<v Speaker 1>And the cluster needs a way to agree on who's

353
00:17:20.960 --> 00:17:22.400
<v Speaker 1>active and who's failed. Right.

354
00:17:22.799 --> 00:17:27.480
<v Speaker 2>That's quorum precisely. Quorum is the voting mechanism. Each node

355
00:17:27.480 --> 00:17:29.960
<v Speaker 2>gets a vote, and sometimes you can figure a witness

356
00:17:30.000 --> 00:17:32.920
<v Speaker 2>like a fileshare or a dedicated disc which also gets

357
00:17:32.960 --> 00:17:35.799
<v Speaker 2>a vote. The cluster needs a majority of votes more

358
00:17:35.839 --> 00:17:39.960
<v Speaker 2>than half to stay online. This prevents split brain scenarios

359
00:17:40.000 --> 00:17:43.240
<v Speaker 2>where network partitions might make two sets of nodes think

360
00:17:43.279 --> 00:17:44.440
<v Speaker 2>they are the active cluster.

361
00:17:44.720 --> 00:17:49.279
<v Speaker 1>Okay, voting insures consistency and Windows Server twenty sixteen introduced

362
00:17:49.359 --> 00:17:52.759
<v Speaker 1>a new type of witness, the cloud witness.

363
00:17:52.920 --> 00:17:56.279
<v Speaker 2>Yes, this is a really neat addition. Instead of needing

364
00:17:56.319 --> 00:17:59.079
<v Speaker 2>a physical disc or a file share somewhere which might

365
00:17:59.119 --> 00:18:01.119
<v Speaker 2>be on one of your main side creating a single

366
00:18:01.160 --> 00:18:03.480
<v Speaker 2>point of failure for the witness itself, you can use

367
00:18:03.480 --> 00:18:06.000
<v Speaker 2>a tiny bit of storage in Microsoft Azure as the

368
00:18:06.039 --> 00:18:07.759
<v Speaker 2>witness resource in the cloud.

369
00:18:07.960 --> 00:18:08.880
<v Speaker 1>Why is that useful?

370
00:18:09.000 --> 00:18:11.559
<v Speaker 2>It's fantastic for stretch clusters where your cluster nodes or

371
00:18:11.559 --> 00:18:14.440
<v Speaker 2>in different physical locations, maybe different buildings or even cities.

372
00:18:14.640 --> 00:18:17.920
<v Speaker 2>Putting the witness in Azure provides a truly independent third location,

373
00:18:18.319 --> 00:18:21.359
<v Speaker 2>making the quorum much more resilient to site failures. Also

374
00:18:21.400 --> 00:18:25.319
<v Speaker 2>great for clusters running entirely in VMS, maybe even Azure VMS.

375
00:18:25.200 --> 00:18:27.799
<v Speaker 1>Removes the need for that third physical site just for

376
00:18:27.839 --> 00:18:31.519
<v Speaker 1>the witness. Glover and Dynamic Quorum AH.

377
00:18:31.640 --> 00:18:34.519
<v Speaker 2>Dynamic Korum has been around since Server twenty twelve, actually

378
00:18:35.000 --> 00:18:39.319
<v Speaker 2>enabled by default. Also very clever. The cluster automatically adjusts

379
00:18:39.359 --> 00:18:42.519
<v Speaker 2>node votes based on their current state. If nodes shut

380
00:18:42.559 --> 00:18:45.400
<v Speaker 2>down gracefully they lose their vote. This means a cluster

381
00:18:45.480 --> 00:18:48.359
<v Speaker 2>can potentially stay online even if it loses multiple nodes

382
00:18:48.759 --> 00:18:51.160
<v Speaker 2>right down to the last single node in some scenarios,

383
00:18:51.440 --> 00:18:54.880
<v Speaker 2>because the required number of votes for quorum adjusts dynamically.

384
00:18:54.960 --> 00:18:57.240
<v Speaker 1>Wow. Okay, so the cluster tries its best to stay

385
00:18:57.319 --> 00:19:00.559
<v Speaker 1>up even as nodes fail. Very resilient. All right. Let's

386
00:19:00.559 --> 00:19:03.119
<v Speaker 1>talk maintenance. Keeping servers healthy. Updates are critical but can

387
00:19:03.160 --> 00:19:03.880
<v Speaker 1>also be risky.

388
00:19:04.079 --> 00:19:09.160
<v Speaker 2>WSUS Windows Server Update Services WSUS is fundamental for managing

389
00:19:09.200 --> 00:19:12.839
<v Speaker 2>Microsoft updates in any reasonably sized organization. Instead of every

390
00:19:12.880 --> 00:19:16.599
<v Speaker 2>single client computer downloading updates directly for Microsoft Update over

391
00:19:16.599 --> 00:19:17.400
<v Speaker 2>the Internet.

392
00:19:17.079 --> 00:19:18.799
<v Speaker 1>Which would kill your bandwidth.

393
00:19:18.359 --> 00:19:22.000
<v Speaker 2>Exactly, Instead, you set up one WSUS server. It downloads

394
00:19:22.000 --> 00:19:25.400
<v Speaker 2>all the improved updates once for Microsoft. Then all your

395
00:19:25.400 --> 00:19:28.279
<v Speaker 2>clients and servers point to your internal WSUS server to

396
00:19:28.279 --> 00:19:29.000
<v Speaker 2>get their updates.

397
00:19:29.160 --> 00:19:33.720
<v Speaker 1>Saves bandwidth. Okay, but the real win is control, right.

398
00:19:34.000 --> 00:19:38.039
<v Speaker 2>That's the biggest benefit. Administrators use WSUS to approve which

399
00:19:38.119 --> 00:19:40.920
<v Speaker 2>updates get deployed. You can test updates on a pilot

400
00:19:40.960 --> 00:19:44.599
<v Speaker 2>group first. You can improve security updates immediately, but maybe

401
00:19:44.599 --> 00:19:47.200
<v Speaker 2>hold back on big feature updates until you're ready, you

402
00:19:47.200 --> 00:19:49.880
<v Speaker 2>get reports on which machines need which updates. Gives you

403
00:19:49.960 --> 00:19:51.720
<v Speaker 2>vital control over the patching process.

404
00:19:51.880 --> 00:19:54.839
<v Speaker 1>Can you delay updates if you need to test more.

405
00:19:54.759 --> 00:19:57.799
<v Speaker 2>Yes, Especially with the newer servicing models, you can typically

406
00:19:57.799 --> 00:20:00.519
<v Speaker 2>defer feature updates the ones that add new cap abilities

407
00:20:00.559 --> 00:20:04.759
<v Speaker 2>for several months, and quality updates. The monthly security patches

408
00:20:04.759 --> 00:20:07.160
<v Speaker 2>and bug fixes can usually be deferred for up to

409
00:20:07.240 --> 00:20:10.839
<v Speaker 2>thirty days using group policy. This gives it time to

410
00:20:10.920 --> 00:20:13.640
<v Speaker 2>test and ensure compatibility before rolling out widely.

411
00:20:13.799 --> 00:20:17.359
<v Speaker 1>That control is absolutely essential in production environments. Okay, what

412
00:20:17.440 --> 00:20:20.200
<v Speaker 1>about protecting against malware? Windows Defender is built in now

413
00:20:20.240 --> 00:20:20.720
<v Speaker 1>right yep.

414
00:20:20.799 --> 00:20:23.839
<v Speaker 2>Windows Defender antimolware is included and enabled by default in

415
00:20:23.880 --> 00:20:27.359
<v Speaker 2>Windows Server twenty sixteen. Unlike some earlier versions, it provides

416
00:20:27.400 --> 00:20:33.160
<v Speaker 2>real time protection, scanning, definition updates, the usual anti war capabilities.

417
00:20:32.559 --> 00:20:33.799
<v Speaker 1>And you can manage it centrally.

418
00:20:34.079 --> 00:20:38.160
<v Speaker 2>You can't typically through group policy for configuration settings or

419
00:20:38.279 --> 00:20:43.480
<v Speaker 2>using PowerShell cmdalits. You can configure exclusion paths, schedule scans,

420
00:20:43.799 --> 00:20:45.119
<v Speaker 2>managed definition updates.

421
00:20:45.319 --> 00:20:47.880
<v Speaker 1>And you mentioned a clever setting for VMS earlier.

422
00:20:48.079 --> 00:20:52.440
<v Speaker 2>Yes, the randomized scheduled task times setting in group policy.

423
00:20:52.440 --> 00:20:55.839
<v Speaker 2>For Defender. This is especially important on hyper v hosts

424
00:20:55.920 --> 00:20:59.480
<v Speaker 2>or FEEDI environments where you might have tens or hundreds.

425
00:20:59.200 --> 00:21:00.920
<v Speaker 1>Of vms, oh I randomize.

426
00:21:01.000 --> 00:21:03.119
<v Speaker 2>If you don't, all those vms might try to run

427
00:21:03.160 --> 00:21:06.000
<v Speaker 2>their scheduled scan or download updates at exactly the same time,

428
00:21:06.119 --> 00:21:09.680
<v Speaker 2>say two point zero am. This can absolutely crush the

429
00:21:09.720 --> 00:21:13.240
<v Speaker 2>host CPU and disc io, making everything grind to a halt.

430
00:21:13.440 --> 00:21:15.680
<v Speaker 2>Randomizing spreads that load out over a window of time

431
00:21:15.680 --> 00:21:17.119
<v Speaker 2>maybe an hour or two, so you don't get those

432
00:21:17.160 --> 00:21:18.119
<v Speaker 2>huge resource spikes.

433
00:21:18.200 --> 00:21:21.759
<v Speaker 1>That is smart prevents a self inflicted performance disaster and

434
00:21:21.880 --> 00:21:24.359
<v Speaker 1>beyond updates in malware, just keeping an eye on things.

435
00:21:24.720 --> 00:21:25.599
<v Speaker 1>Monitoring tools.

436
00:21:25.720 --> 00:21:28.440
<v Speaker 2>Window Server has a whole suite. You've got the quick

437
00:21:28.440 --> 00:21:31.519
<v Speaker 2>overview of task manager, deeper dives with resource monitor and

438
00:21:31.519 --> 00:21:35.480
<v Speaker 2>Performance monitor for tracking CPU memory, disc network usage over time,

439
00:21:35.799 --> 00:21:37.240
<v Speaker 2>and critically.

440
00:21:36.960 --> 00:21:38.920
<v Speaker 1>Event Viewer ah the logs.

441
00:21:39.119 --> 00:21:43.359
<v Speaker 2>Everything gets logged there, system events, application error, security audits.

442
00:21:43.599 --> 00:21:47.319
<v Speaker 2>But the really powerful part for larger environments is event subscriptions.

443
00:21:48.160 --> 00:21:51.359
<v Speaker 2>You can configure servers to forward specific events to a

444
00:21:51.440 --> 00:21:53.279
<v Speaker 2>central collector server, so.

445
00:21:53.359 --> 00:21:55.480
<v Speaker 1>You don't have to log into fifty servers to check

446
00:21:55.519 --> 00:21:56.720
<v Speaker 1>their logs exactly.

447
00:21:56.839 --> 00:22:00.000
<v Speaker 2>You get one consolidated forwarded events log with all your

448
00:22:00.000 --> 00:22:03.519
<v Speaker 2>important stuff from multiple systems makes monitoring and troubleshooting way

449
00:22:03.519 --> 00:22:04.079
<v Speaker 2>more efficient.

450
00:22:04.160 --> 00:22:06.720
<v Speaker 1>Okay, we've covered a lot of ground on traditional server

451
00:22:06.880 --> 00:22:10.559
<v Speaker 1>roles and virtualization. Let's shift to something newer, more cutting

452
00:22:10.599 --> 00:22:14.559
<v Speaker 1>edge for server twenty sixteen Windows containers. How are these

453
00:22:14.599 --> 00:22:16.200
<v Speaker 1>different from hypervvms?

454
00:22:16.400 --> 00:22:20.799
<v Speaker 2>Fundamentally different approach. Hyper v virtualizes the hardware. Each VM

455
00:22:20.920 --> 00:22:24.519
<v Speaker 2>gets its own entire operating system, its own kernel drivers,

456
00:22:24.839 --> 00:22:27.920
<v Speaker 2>it's a full machine simulation. Containers, on the other hand,

457
00:22:28.559 --> 00:22:30.599
<v Speaker 2>virtualized parts of the operating system.

458
00:22:30.279 --> 00:22:32.599
<v Speaker 1>Itself, virtualize THEOS. How does that work?

459
00:22:32.720 --> 00:22:36.880
<v Speaker 2>The key concept is namespace isolation. All the containers running

460
00:22:36.920 --> 00:22:40.359
<v Speaker 2>on a host actually share the host operating systems kernel,

461
00:22:41.359 --> 00:22:44.240
<v Speaker 2>but each container gets its own isolated view of things

462
00:22:44.279 --> 00:22:48.799
<v Speaker 2>like the file system, the registry, network, ports process lists.

463
00:22:49.160 --> 00:22:51.480
<v Speaker 1>So they think they have their own OS, but they're

464
00:22:51.480 --> 00:22:54.240
<v Speaker 1>really just using segregated parts of the host OS.

465
00:22:54.279 --> 00:22:58.519
<v Speaker 2>In essence. Yes, the hosts kernel manages this isolation, only

466
00:22:58.519 --> 00:23:01.359
<v Speaker 2>showing each container the resource is allocated to it. It's

467
00:23:01.440 --> 00:23:04.279
<v Speaker 2>much lighter weight than a full VM because you don't

468
00:23:04.279 --> 00:23:07.160
<v Speaker 2>have that overhead of a separate OS kernel and duplicate

469
00:23:07.200 --> 00:23:09.079
<v Speaker 2>system files for every single instance.

470
00:23:09.440 --> 00:23:13.359
<v Speaker 1>Lighter weight means faster startup, more density on a host exactly.

471
00:23:13.519 --> 00:23:16.400
<v Speaker 2>Containers can often start in seconds compared to minutes for

472
00:23:16.440 --> 00:23:19.359
<v Speaker 2>a VM, and you can typically run many more containers

473
00:23:19.400 --> 00:23:22.160
<v Speaker 2>on the same hardware compared to vms. Plus the host

474
00:23:22.160 --> 00:23:25.119
<v Speaker 2>DOS can enforce resource constraints. You can tell a container

475
00:23:25.200 --> 00:23:27.839
<v Speaker 2>you only get to use one CPU core, or you're

476
00:23:27.880 --> 00:23:30.119
<v Speaker 2>limited to five hundred and twelve million bit of RAMS.

477
00:23:30.200 --> 00:23:33.200
<v Speaker 1>So one noisy container doesn't hog all the resources from

478
00:23:33.200 --> 00:23:33.799
<v Speaker 1>its neighbors.

479
00:23:33.880 --> 00:23:37.559
<v Speaker 2>Right ensures fair sharing and predictable performance in multi tenant scenarios.

480
00:23:37.799 --> 00:23:40.440
<v Speaker 1>Now I heard there were two types of Windows containers

481
00:23:40.440 --> 00:23:41.640
<v Speaker 1>in server twenty sixteen.

482
00:23:41.759 --> 00:23:44.720
<v Speaker 2>That's correct, you have Windows Server containers. These provide that

483
00:23:44.799 --> 00:23:47.759
<v Speaker 2>process and namespace isolation. We just talked about sharing the

484
00:23:47.799 --> 00:23:49.599
<v Speaker 2>host kernel directly. They're the fastest and.

485
00:23:49.640 --> 00:23:52.279
<v Speaker 1>Lightest option, okay, and the other type.

486
00:23:52.279 --> 00:23:55.440
<v Speaker 2>Hyper V containers. These offer an extra layer of isolation.

487
00:23:56.039 --> 00:23:59.759
<v Speaker 2>Each hyper V container actually runs inside a very minimal,

488
00:24:00.119 --> 00:24:05.400
<v Speaker 2>highly optimized special purpose virtual machine. Crucially, each container gets

489
00:24:05.400 --> 00:24:07.359
<v Speaker 2>its own copy of the Windows.

490
00:24:07.000 --> 00:24:09.920
<v Speaker 1>Kernel AH, so they don't share the host kernel.

491
00:24:10.000 --> 00:24:13.680
<v Speaker 2>Correct, they still share hardware resources, but the kernel isolation

492
00:24:13.799 --> 00:24:16.720
<v Speaker 2>is much stronger, almost like a full VM, but still

493
00:24:16.799 --> 00:24:19.519
<v Speaker 2>much lighter and faster to deploy than a traditional VM.

494
00:24:19.559 --> 00:24:21.160
<v Speaker 1>Why would you need that extra isolation.

495
00:24:21.400 --> 00:24:24.400
<v Speaker 2>Maybe you're running untrusted code, or you have strict multi

496
00:24:24.400 --> 00:24:28.079
<v Speaker 2>tenant security requirements where even kernel level sharing isn't acceptable,

497
00:24:28.680 --> 00:24:31.599
<v Speaker 2>or perhaps the application inside the container needs a different

498
00:24:31.880 --> 00:24:35.799
<v Speaker 2>kernel version or patch level than the host. OS. Hyper

499
00:24:35.880 --> 00:24:38.240
<v Speaker 2>v containers provide that stronger boundary.

500
00:24:37.920 --> 00:24:41.720
<v Speaker 1>So a spectrum of isolation options and managing all these

501
00:24:41.759 --> 00:24:43.400
<v Speaker 1>container Docker is the tool for that.

502
00:24:43.720 --> 00:24:47.240
<v Speaker 2>Docker became the de facto's standard pretty quickly. It's the

503
00:24:47.240 --> 00:24:49.960
<v Speaker 2>command line tool and engine you use to build, ship

504
00:24:50.000 --> 00:24:53.920
<v Speaker 2>and run containers. You use Docker commands to download basos

505
00:24:53.960 --> 00:24:56.000
<v Speaker 2>images from repositories like Docker.

506
00:24:55.799 --> 00:24:59.440
<v Speaker 1>Hub, which is like an app store for container images.

507
00:24:59.279 --> 00:25:02.400
<v Speaker 2>Kind of yeah, a huge public registry with official images

508
00:25:02.440 --> 00:25:08.000
<v Speaker 2>for Windowserver, Core, Nanoserver, Linux distributions, applications. Then you use

509
00:25:08.079 --> 00:25:11.559
<v Speaker 2>Docker to build your own application layers on top, create

510
00:25:11.599 --> 00:25:14.720
<v Speaker 2>new images, and then run stop list and manage your

511
00:25:14.759 --> 00:25:16.599
<v Speaker 2>running containers and networking.

512
00:25:16.640 --> 00:25:20.559
<v Speaker 1>For containers, how do external users reach an app inside

513
00:25:20.559 --> 00:25:21.200
<v Speaker 1>a container?

514
00:25:21.680 --> 00:25:25.200
<v Speaker 2>Docker handles port mapping. You tell docer map port eighty

515
00:25:25.200 --> 00:25:27.359
<v Speaker 2>on the host machine to port eighty eighty inside this

516
00:25:27.400 --> 00:25:30.799
<v Speaker 2>web server container. Then traffic hitting the host on port

517
00:25:30.839 --> 00:25:33.799
<v Speaker 2>eighty gets automatically forwarded to the application inside the container.

518
00:25:34.000 --> 00:25:36.440
<v Speaker 2>Docker manages all that virtual networking behind the scenes.

519
00:25:36.480 --> 00:25:39.000
<v Speaker 1>Makes sense, It orchestrates the whole life cycle, it really does.

520
00:25:39.039 --> 00:25:41.200
<v Speaker 2>It's simplified container usage dramatically.

521
00:25:41.279 --> 00:25:44.279
<v Speaker 1>Wow, we've covered a ton of ground today. We started

522
00:25:44.279 --> 00:25:46.119
<v Speaker 1>by just redefining what a server even.

523
00:25:46.079 --> 00:25:48.440
<v Speaker 2>Is, right, moving beyond just the box, and.

524
00:25:48.440 --> 00:25:53.440
<v Speaker 1>Then dove into Windows Server twenty sixteen's capabilities. Flexible storage

525
00:25:53.440 --> 00:25:57.079
<v Speaker 1>with storage spaces and ded up, powerful virtualization with hyper

526
00:25:57.160 --> 00:25:58.920
<v Speaker 1>v and all its networking tricks.

527
00:25:58.720 --> 00:26:01.440
<v Speaker 2>Live migration, VM resiliency.

528
00:26:01.000 --> 00:26:05.039
<v Speaker 1>Robust high availability using NLB and failover clusters including that

529
00:26:05.119 --> 00:26:06.440
<v Speaker 1>clever cloud witness.

530
00:26:06.119 --> 00:26:10.319
<v Speaker 2>And proactive maintenance with WSUS and Defender plus smart.

531
00:26:09.960 --> 00:26:13.839
<v Speaker 1>Monitoring, and finally, the agile world of Windows containers managed

532
00:26:13.839 --> 00:26:16.359
<v Speaker 1>by Docker. It's really quite an ecosystem.

533
00:26:16.559 --> 00:26:19.400
<v Speaker 2>It truly is. The amount of engineering that goes into

534
00:26:19.400 --> 00:26:23.839
<v Speaker 2>making all this work reliably, securely, efficiently. It's pretty incredible,

535
00:26:23.880 --> 00:26:26.359
<v Speaker 2>all aimed at keeping your digital services running smoothly.

536
00:26:26.640 --> 00:26:30.079
<v Speaker 1>So thinking about the bigger picture, this invisible work done

537
00:26:30.119 --> 00:26:33.519
<v Speaker 1>by server operating systems like Windows Server twenty sixteen is

538
00:26:33.559 --> 00:26:35.400
<v Speaker 1>just becoming more and more critical, isn't it?

539
00:26:35.599 --> 00:26:39.599
<v Speaker 2>Absolutely? As we rely more on distributed services cloud platforms,

540
00:26:39.960 --> 00:26:43.160
<v Speaker 2>the intelligence baked into the OS layer is paramount, which

541
00:26:43.240 --> 00:26:45.599
<v Speaker 2>leads to a thought. Is that line between a server

542
00:26:45.799 --> 00:26:48.599
<v Speaker 2>and just any other powerful computer becoming kind of blurry?

543
00:26:48.920 --> 00:26:52.200
<v Speaker 1>Or is it just constantly being redefined? Maybe it's less

544
00:26:52.240 --> 00:26:54.839
<v Speaker 1>about the label server and more about the capabilities and

545
00:26:54.839 --> 00:26:58.000
<v Speaker 1>resilience provided by the software wherever it happens to run.

546
00:26:58.359 --> 00:27:00.960
<v Speaker 2>That's a great way to put it. The function defines it,

547
00:27:01.200 --> 00:27:04.319
<v Speaker 2>not necessarily the form factor. So for everyone listening, what

548
00:27:04.559 --> 00:27:07.799
<v Speaker 2>aspect of all this tech sparks your curiosity? What might

549
00:27:07.839 --> 00:27:09.359
<v Speaker 2>you want to dive deeper into next?

550
00:27:09.559 --> 00:27:12.960
<v Speaker 1>Definitely something to think about as you navigate our increasingly

551
00:27:13.000 --> 00:27:13.799
<v Speaker 1>digital world.