Speaker 1: Welcome to the deep dive, where we take your source
Speaker 1: material and uncover the most fascinating insights. So when you
Speaker 1: hear the word server, what's the first image that pops
Speaker 1: into your head.
Speaker 2: Yeah, probably you know, a big humming box in a
Speaker 2: data center somewhere, lots of blinking lights, tons of hardware,
Speaker 2: that kind of thing.
Speaker 1: Exactly that classic image. But what if we told you
Speaker 1: that the real core of what makes a server well,
Speaker 1: a server isn't really the box itself. It's actually all
Speaker 1: about the software.
Speaker 2: Running on it. It's a really fundamental shift in thinking,
Speaker 2: isn't it, And it really underpins almost everything we do
Speaker 2: in modern IT these days. Today we're going to dive
Speaker 2: deep into Windows Server twenty sixteen. Well, look at its
Speaker 2: core technologies, how it delivers robus services, make sure things
Speaker 2: stay up and running, high availability, and how it really
Speaker 2: embraces modern computing precisely.
Speaker 1: So, whether you're maybe mapping out your next IT project
Speaker 1: or prepping for a meeting, or maybe you're just curious
Speaker 1: about what makes the digital world tick, we're here to
Speaker 1: give you that.
Speaker 2: Yeah, gets you those aha moments, you know, without drowning
Speaker 2: you in technical jargon.
Speaker 1: Exactly, So over the next few minutes, we'll unpack how
Speaker 1: even simple hardware can become a powerhouse. We'll get into
Speaker 1: some really clever storage tricks.
Speaker 2: Oh yeah, storage spaces indeed, depth good stuff there.
Speaker 1: Peek into virtualization and containers, and uncover some secrets to
Speaker 1: keeping everything online pretty much all the time.
Speaker 2: Sounds like a plan.
Speaker 1: Okay, So let's tackle that server image head on. You
Speaker 1: said it's less about the box, more the software the mindset.
Speaker 1: Can you break that down a bit, because it really does.
Speaker 2: Change things absolutely. That old idea of a server just
Speaker 2: being beef hardware is well, it's kind of outdated. Now.
Speaker 2: A computer becomes a server when you install software on
Speaker 2: it that's built to provide network services.
Speaker 1: So like rolls and features.
Speaker 2: Exactly roles and features that serve clients. You could theoretically
Speaker 2: take an inexpensive laptop, install the right software and boom,
Speaker 2: it's a server for some specific task. And conversely, you
Speaker 2: could have this absolute beast of a machine loaded with
Speaker 2: processors in RAM. But if it's just running desktop apps
Speaker 2: for one person, it's just a powerful workstation, right.
Speaker 1: So the difference isn't just raw horsepower, it's the job
Speaker 1: it's doing. The specialized functions. What kind of things does
Speaker 1: Windows Server twenty sixteen do that, say, my Windows ten
Speaker 1: machine just can't.
Speaker 2: Ah, that's the key distinction. Windows Server is built from
Speaker 2: the ground up for resilience, for scale, for running twenty
Speaker 2: four to seven. It has things like built in fault
Speaker 2: tolerance features like ray.
Speaker 1: Five volumes okay, redundant array of independent disks level five.
Speaker 2: Right, plus sophisticated load balancing, clustering, stuff you just don't
Speaker 2: find in a standard desktop OS like Windows ten.
Speaker 1: And the hardware support is different too, lassively different.
Speaker 2: Windows Server twenty sixteen can handle I think up to
Speaker 2: sixty four processors compared to just two for Windows ten
Speaker 2: pro wow and users. Windows ten might limit you to
Speaker 2: maybe twenty network connections. Windows Server Standard or data center.
Speaker 2: It's basically unlimited by the OS itself. You're limited by
Speaker 2: your licenses and how much the hardware can handle. Is
Speaker 2: designed for hundreds of thousands of users.
Speaker 1: Okay, that pains a really clear picture. It's built for
Speaker 1: mission critical stuff. Now let's talk storage. That's always huge, right, bottlenecks, failures.
Speaker 1: How does Windows Server twenty sixteen handle discs smartly?
Speaker 2: Yes? Storage tech has come a long way. Storage spaces
Speaker 2: in Windows Server twenty sixteen is a great example. It
Speaker 2: lets you take a bunch of different physical drives USB, SATA, SaaS, internal, external,
Speaker 2: even different sizes, and pool them together, cool them. Yeah,
Speaker 2: create a storage pool, and then you carve out virtual
Speaker 2: discs from that pool. These virtual discs can be flexible,
Speaker 2: fault tolerant, and you don't necessarily need those expensive hardware
Speaker 2: rate controllers anymore.
Speaker 1: That flexibility sounds amazing, especially if you've got mixed hardware
Speaker 1: lying around and you mentioned something about capacity planning. Thin
Speaker 1: provisioning that sounds interesting.
Speaker 2: Oh, thin provision is brilliant. I mean you can create
Speaker 2: a virtual disc and tell the system, okay, this volume
Speaker 2: can grow up to say t terabytes, right, But the
Speaker 2: system doesn't actually grab all ten terabytes of physical disk
Speaker 2: space right away. It only allocates space from the pool
Speaker 2: as data is actually written to the volume.
Speaker 1: Ah. So you provision big, but you only pay for
Speaker 1: or use the physical space you need. Now that must
Speaker 1: be huge for managing costs and scaling.
Speaker 2: It absolutely is huge for optimizing resources, deferring hardware purchases,
Speaker 2: and for resilience within storage spaces. You've got good options.
Speaker 2: Mirror space is like grade one.
Speaker 1: Okay, data is duplicated, right.
Speaker 2: A two way mirror writes data to two discs, so
Speaker 2: it can survive one disc failing needs at least two
Speaker 2: physical discs for more protection. A three way mirror writs
Speaker 2: to three.
Speaker 1: Discs, needs five discs total for that though.
Speaker 2: It needs five physical discs. Yeah, but it can survive
Speaker 2: two disc failures. Mirroring is generally recommended for pretty much
Speaker 2: any storage that needs resilience in good.
Speaker 1: Performance okay, so it's top performance, top aliability with mirroring.
Speaker 1: What if you need to be more space efficient, maybe
Speaker 1: for backups or archives.
Speaker 2: That's where parity space comes in. It's more like five
Speaker 2: or RAD six. A single parity space stripes data and
Speaker 2: parity info across discs. These at least three discs can
Speaker 2: handle one.
Speaker 1: Failure, and dual parody.
Speaker 2: Dual parody uses two sets of parity info, needs at
Speaker 2: least seven discs and can survive two failures. It's much
Speaker 2: more space efficient than mirroring.
Speaker 1: But there's always a butt, but.
Speaker 2: The right performance is generally lower calculating that parity takes
Speaker 2: some overhead, so parity spaces are usually better for things
Speaker 2: like archival storage backups. Data that isn't constantly being written
Speaker 2: to at high speed?
Speaker 1: Got it? Balancing acts between space performance and resilience. Okay,
Speaker 1: so we've organized the disks, what about actually saving space
Speaker 1: on them. Data d duplication sounds almost like magic.
Speaker 2: It does seem like magic sometimes. Data d duplication or
Speaker 2: d DEP is seriously impressive tech. It uses a combination
Speaker 2: of compression and finding duplicate data.
Speaker 1: Blocks blocks, not just whole five right blocks.
Speaker 2: So imagine you have ten copies of almost the same
Speaker 2: PowerPoint presentation, maybe just the title slide changed, or lots
Speaker 2: of virtual machine files that share common OS components. DTA
Speaker 2: finds those identical blocks.
Speaker 1: Of data and just stores one copy exactly.
Speaker 2: It stores one unique copy of the block and replaces
Speaker 2: all the other instances with tiny pointers back to that
Speaker 2: single copy.
Speaker 1: So all that redundant data just kind of evaporates, leaving
Speaker 1: one real copy. What kind of savings are we talking
Speaker 1: and any catches?
Speaker 2: The savings can be really dramatic for things like user documents,
Speaker 2: software install shares, VHD libraries. You often see fifty percent
Speaker 2: to even ninety percent space savings. It's pretty common.
Speaker 1: Wow.
Speaker 2: But yeah, there are limitations. It doesn't work well or
Speaker 2: at all on encrypted files or on very small files
Speaker 2: generally under thirty two KP okay, And you need to
Speaker 2: keep some free space on the volume for it to
Speaker 2: work efficiently, usually at least ten percent. Also a key
Speaker 2: point for twenty sixteen, it wasn't supported on cluster shared
Speaker 2: volumes csvs for active workloads back then.
Speaker 1: Good caveats to remember. Okay, storage is flexible efficient, But
Speaker 1: what about the big like a whole server dying or
Speaker 1: even a whole site going offline. That's where storage replica
Speaker 1: comes in.
Speaker 2: I assume absolutely. Storage Replica is your lifeline for disaster recovery,
Speaker 2: for business continuity. It lets you replicate entire volumes between
Speaker 2: servers or even between entire clusters.
Speaker 1: Replica like keep an exact copy somewhere else precisely.
Speaker 2: And the big choice here is how you replicate synchronous
Speaker 2: or asynchronous?
Speaker 1: Okay, what's the difference?
Speaker 2: Synchronous replication is this super safe option. When your application
Speaker 2: writes data, the system waits until that data is successfully
Speaker 2: written to both the main site and the replica site
Speaker 2: before it tells the application okay done, ah.
Speaker 1: So zero data loss guaranteed, even if the main site
Speaker 1: instantly disappears.
Speaker 2: Exactly zero data loss guarantee, But it needs a really fast,
Speaker 2: low latency network connection between the sites because that wait
Speaker 2: time adds latencyed every single right operation.
Speaker 1: Right, physics gets in the way. So what's the alternative
Speaker 1: if your sites are far apart or the network isn't super.
Speaker 2: Fast, that's asynchronous replication. With async the right happens on
Speaker 2: the source. First, the system tells the app okay done.
Speaker 2: Then it sends the data over to the replica site.
Speaker 1: So faster for the application, but there's a small window.
Speaker 2: There's a small potential for data loss. If the source
Speaker 2: fails suddenly before the data makes it to the replica,
Speaker 2: that last little bit might be lost. But it works
Speaker 2: great over longer distances, higher latency networks.
Speaker 1: So you trade that tiny risk for geographical flexibility. Makes sense.
Speaker 1: It's about choosing the right tool for the job based
Speaker 1: on your recovery needs and network exactly right.
Speaker 2: It gives you critical options.
Speaker 1: Okay, we've got solid storage foundations. Now let's move up
Speaker 1: a layer into the virtual world hyper V. That's Windows
Speaker 1: servers built in Hypervisor right the heart of its virtualization.
Speaker 2: Ye, piper V is a server role. You install it
Speaker 2: basically creates this software layer that mimics hardware, lets you
Speaker 2: run multiple operating systems. We call them guest os is
Speaker 2: all running isolator from each other on just one physical machine,
Speaker 2: the host.
Speaker 1: It's like having a whole rack of servers condensed into
Speaker 1: one box.
Speaker 2: Pretty much, massive boost in hardware utilization, simplifies management, speeds
Speaker 2: up deployment. It's fundamental to modern data centers.
Speaker 1: And these virtual machines. They need virtual hard drives vhds.
Speaker 1: What are the options there?
Speaker 2: Mainly see three types of virtual discs. Fixed sized discs
Speaker 2: are kind of the old school way. You create one
Speaker 2: hundred GMBVHD, it immediately takes up one hundred gigabe on
Speaker 2: your host's storage.
Speaker 1: Even if it's empty inside.
Speaker 2: Even if it's empty, the benefit is slightly better performance sometimes,
Speaker 2: especially for really disc heavy apps, because the system doesn't
Speaker 2: have to resize the file on the fly.
Speaker 1: Okay, what's more common.
Speaker 2: Now dynamically expanding discs. These are much more flexible. You
Speaker 2: still set a maximum size, say one hundred gigaby, but
Speaker 2: the actual VHD file on the host starts tiny and
Speaker 2: only grows as you add data inside the.
Speaker 1: Vm AH like thin provisioning for VHDS saves host disk space.
Speaker 2: Exactly great choice for most vms unless you have extreme
Speaker 2: disc io needs, and then there's a special care pass
Speaker 2: through discs pass through. Yeah, this isn't actually a virtual
Speaker 2: disc file. You take a physical disc attached to the host,
Speaker 2: get it offline in the host OS, and then you
Speaker 2: attach that entire physical disc directly to a VM. The
Speaker 2: VM gets raw access.
Speaker 1: Why would you do that?
Speaker 2: Maybe you have data already on that physical disc you
Speaker 2: want the VM to access directly, or some very specific
Speaker 2: performance scenario. It bypasses the virtual disc layer.
Speaker 1: Interesting niche case, and the file formats VHD versus VHDX right.
Speaker 2: VHD is the older format, limited to two terabytes per
Speaker 2: virtual disc. VHDX is the newer format introduced later. It
Speaker 2: supports much larger discs up to sixty four carabytes, has
Speaker 2: better performance, and includes features like resilience against corruption if
Speaker 2: there's a power failure during a rite. Generally you want
Speaker 2: to use VHDX for new vms.
Speaker 1: Could tip okay, VM's virtual discs. How do they talk
Speaker 1: to each other and to the outside world Virtual networks YEP.
Speaker 2: Through virtual networks managed by virtual switches. There are three
Speaker 2: main types of virtual switches you can create in hyper
Speaker 2: v Okay, an external virtual switch links your VMS to
Speaker 2: a physical network adapter and I see on the host.
Speaker 2: This lets the vms talk to the physical network, the Internet,
Speaker 2: other physical machines, and the host itself. It's the most common.
Speaker 1: Type, makes sense, connects virtual to physical What.
Speaker 2: Else an internal virtual switch. This creates a network that
Speaker 2: only the vms on that host and the host itself
Speaker 2: can use. They can all talk to each other, but
Speaker 2: they cannot reach the physical network beyond the host.
Speaker 1: Ah isolated, but the host is included right.
Speaker 2: And finally, a private virtual switch. This is total isolation.
Speaker 2: Only the vms connected to that private switch can talk
Speaker 2: to each other. They can't even talk to the host machine,
Speaker 2: let alone the physical network.
Speaker 1: Okay, useful for sandboxing or specific tiered applications, maybe.
Speaker 2: Exactly, security boundaries, testing labs, things like that.
Speaker 1: Now within these virtual networks, especially the external ones, are
Speaker 1: there more advanced controls? How do you manage traffic or
Speaker 1: security more granularly? Oh?
Speaker 2: Yes, lots of advanced features. Volume IDs. For example, just
Speaker 2: like on physical switches, you can sign vland tags to
Speaker 2: virtual network adapters. This lets you segment traffic from different
Speaker 2: vms onto different logical networks, even if they're all connected
Speaker 2: to the same external virtual switch.
Speaker 1: So better organization and security without needing tons of physical NICs. Smart.
Speaker 1: What about MAC address spoofing That sounds bad?
Speaker 2: Huh? Usually, yes, you don't want machines just pretending to
Speaker 2: be other machines, But hyper v lets you enable MAC
Speaker 2: scoofing on a VM's virtual NIC for specific reasons like what.
Speaker 2: Certain types of network clustering inside the vms, like network
Speaker 2: load balancing NLP, sometimes require the VM to be able
Speaker 2: to use a shared or virtual MC address, so you
Speaker 2: enable spoofing just for those specific vms that need it.
Speaker 1: AH unnecessary evil in some cases, Okay. Any other key
Speaker 1: security features in virtual networking.
Speaker 2: DHDP guard is a big one. You really want this
Speaker 2: enabled on pretty much all your vms do. It prevents
Speaker 2: that VM from acting like a DHCP server, you know,
Speaker 2: the service that hands out IP addresses. A rogue DHGP
Speaker 2: server may be accidentally started by a user in side
Speaker 2: of VM, or even maliciously can cause chaos on your network.
Speaker 1: Right handing out bad IP addresses, disrupting everyone exactly.
Speaker 2: So DHP guard blocks the outgoing DXCP server messages from
Speaker 2: that VM. You only leave it disabled on your actual
Speaker 2: authorized DHGP server.
Speaker 1: VMS critical security setting them and you can even do
Speaker 1: NIC teaming inside of VM, like team up virtual NICs.
Speaker 2: You can even if the host server already has physical
Speaker 2: NICs teamed, you can create another team inside the VM.
Speaker 2: Using multiple virtual NICs connected to the same switch gives
Speaker 2: you redundancy or potentially more bandwidth within that specific Virtual
Speaker 2: machines operating system.
Speaker 1: Wow. Layers upon layers of flexibility and resilience. Speaking of resilience,
Speaker 1: moving VMS around without downtime live migration that still sounds
Speaker 1: like magic to me.
Speaker 2: It really is one of the coolest things hypervw does.
Speaker 2: Live migration lets you move a running virtual machine, operating system, applications,
Speaker 2: memory state everything from one hyper v host server to
Speaker 2: another without any interruption to the service or the connected users.
Speaker 1: Seriously, no downtime at all, zero.
Speaker 2: Perceived downtime for the end user. If everything is configured correctly.
Speaker 2: You can use to drain a host for maintenance balance
Speaker 2: workloads across hosts. It's incredibly powerful for keeping things running smoothly.
Speaker 1: That's amazing for infrastructure management. And you can move just
Speaker 1: the storage too. Without moving the whole VM.
Speaker 2: Yep, that's storage migration. You can move the VHD files
Speaker 2: of running VM from one storage location, say one lun
Speaker 2: or share, to another without interrupting the VM, and without
Speaker 2: moving it to a different host server.
Speaker 1: Useful for storage maintenance or moving to faster discs.
Speaker 2: I guess exactly, rebalanced storage upgrade arrays migrate off a
Speaker 2: hardware all while the VM keeps running.
Speaker 1: Now, what about those little glitches like a temporary network
Speaker 1: hiccup to the storage. Does the VM just crash? I
Speaker 1: heard twenty sixteen improve this with VM resiliency.
Speaker 2: It did make a significant improvement there. Before, if a
Speaker 2: clustered VM briefly lost connection to its storage, it might
Speaker 2: just fail over, causing a small outage. In Windows Server
Speaker 2: twenty sixteen, especially with vms stored on cluster shared volumes csvs,
Speaker 2: things got smarter. Oh, so, if a VM loses access
Speaker 2: to its storage, instead of immediately crashing or failing over,
Speaker 2: it might enter a temporary pause critical state. It just
Speaker 2: waits for how long, potentially up to thirty minutes. If
Speaker 2: the storage connection comes back within that time, maybe it
Speaker 2: was just a network leitch, a switch rebooting the VM
Speaker 2: automatically resumes right where it left off.
Speaker 1: No failover, no reboot, just resumes, just resumes.
Speaker 2: It turns a potential outage into just a temporary pause,
Speaker 2: often unnoticed by users. It's a huge wind for stability,
Speaker 2: especially in complex environments where transient storage issues can happen.
Speaker 1: That's incredibly practical. Okay, shifting focus slightly to keeping services
Speaker 1: highly available, not just individual VMS Network load balancing LB.
Speaker 1: What's its role?
Speaker 2: NLB is great for scaling out applications that are mostly stateless,
Speaker 2: meaning they don't need to remember a complot details about
Speaker 2: each user's session from one request to the next. Think
Speaker 2: web servers serving stack content or maybe media streaming servers.
Speaker 1: How does it work.
Speaker 2: You set up multiple servers nodes running the same application.
Speaker 2: LB presents a single virtual IP address to the clients
Speaker 2: when requests come in, and LB distributes them across the
Speaker 2: active nodes in the cluster. If one node fails, and
Speaker 2: I'll be just stop sending traffic to it.
Speaker 1: So more capacity and some basic fault tolerance for those
Speaker 1: kinds of.
Speaker 2: Apps exactly good for scaling out, but for applications that
Speaker 2: are stateful or need true automatic failover of the service itself.
Speaker 2: You need something more robust.
Speaker 1: Which brings us to failover clusters.
Speaker 2: Right. Failover clustering is the heavyweight champion of high availability
Speaker 2: in the Windows world. You typically have two or more
Speaker 2: servers nodes connected to some form of shared storage.
Speaker 1: Shared storage is key here.
Speaker 2: Absolutely the application data, the configuration, maybe the VM files.
Speaker 2: If it's a hyperv cluster, it all is on storage
Speaker 2: accessible by all nodes. Only one node is active for
Speaker 2: a given cluster roll at a time. If that active node.
Speaker 1: Fails, another node takes over exactly.
Speaker 2: The cluster service detects the failure, brings the application resources
Speaker 2: online on a passive node, which then becomes active. Clients
Speaker 2: connect using a cluster name or IP address which follows
Speaker 2: the active node, so the transition is often seamless or
Speaker 2: very brief.
Speaker 1: And the cluster needs a way to agree on who's
Speaker 1: active and who's failed. Right.
Speaker 2: That's quorum precisely. Quorum is the voting mechanism. Each node
Speaker 2: gets a vote, and sometimes you can figure a witness
Speaker 2: like a fileshare or a dedicated disc which also gets
Speaker 2: a vote. The cluster needs a majority of votes more
Speaker 2: than half to stay online. This prevents split brain scenarios
Speaker 2: where network partitions might make two sets of nodes think
Speaker 2: they are the active cluster.
Speaker 1: Okay, voting insures consistency and Windows Server twenty sixteen introduced
Speaker 1: a new type of witness, the cloud witness.
Speaker 2: Yes, this is a really neat addition. Instead of needing
Speaker 2: a physical disc or a file share somewhere which might
Speaker 2: be on one of your main side creating a single
Speaker 2: point of failure for the witness itself, you can use
Speaker 2: a tiny bit of storage in Microsoft Azure as the
Speaker 2: witness resource in the cloud.
Speaker 1: Why is that useful?
Speaker 2: It's fantastic for stretch clusters where your cluster nodes or
Speaker 2: in different physical locations, maybe different buildings or even cities.
Speaker 2: Putting the witness in Azure provides a truly independent third location,
Speaker 2: making the quorum much more resilient to site failures. Also
Speaker 2: great for clusters running entirely in VMS, maybe even Azure VMS.
Speaker 1: Removes the need for that third physical site just for
Speaker 1: the witness. Glover and Dynamic Quorum AH.
Speaker 2: Dynamic Korum has been around since Server twenty twelve, actually
Speaker 2: enabled by default. Also very clever. The cluster automatically adjusts
Speaker 2: node votes based on their current state. If nodes shut
Speaker 2: down gracefully they lose their vote. This means a cluster
Speaker 2: can potentially stay online even if it loses multiple nodes
Speaker 2: right down to the last single node in some scenarios,
Speaker 2: because the required number of votes for quorum adjusts dynamically.
Speaker 1: Wow. Okay, so the cluster tries its best to stay
Speaker 1: up even as nodes fail. Very resilient. All right. Let's
Speaker 1: talk maintenance. Keeping servers healthy. Updates are critical but can
Speaker 1: also be risky.
Speaker 2: WSUS Windows Server Update Services WSUS is fundamental for managing
Speaker 2: Microsoft updates in any reasonably sized organization. Instead of every
Speaker 2: single client computer downloading updates directly for Microsoft Update over
Speaker 2: the Internet.
Speaker 1: Which would kill your bandwidth.
Speaker 2: Exactly, Instead, you set up one WSUS server. It downloads
Speaker 2: all the improved updates once for Microsoft. Then all your
Speaker 2: clients and servers point to your internal WSUS server to
Speaker 2: get their updates.
Speaker 1: Saves bandwidth. Okay, but the real win is control, right.
Speaker 2: That's the biggest benefit. Administrators use WSUS to approve which
Speaker 2: updates get deployed. You can test updates on a pilot
Speaker 2: group first. You can improve security updates immediately, but maybe
Speaker 2: hold back on big feature updates until you're ready, you
Speaker 2: get reports on which machines need which updates. Gives you
Speaker 2: vital control over the patching process.
Speaker 1: Can you delay updates if you need to test more.
Speaker 2: Yes, Especially with the newer servicing models, you can typically
Speaker 2: defer feature updates the ones that add new cap abilities
Speaker 2: for several months, and quality updates. The monthly security patches
Speaker 2: and bug fixes can usually be deferred for up to
Speaker 2: thirty days using group policy. This gives it time to
Speaker 2: test and ensure compatibility before rolling out widely.
Speaker 1: That control is absolutely essential in production environments. Okay, what
Speaker 1: about protecting against malware? Windows Defender is built in now
Speaker 1: right yep.
Speaker 2: Windows Defender antimolware is included and enabled by default in
Speaker 2: Windows Server twenty sixteen. Unlike some earlier versions, it provides
Speaker 2: real time protection, scanning, definition updates, the usual anti war capabilities.
Speaker 1: And you can manage it centrally.
Speaker 2: You can't typically through group policy for configuration settings or
Speaker 2: using PowerShell cmdalits. You can configure exclusion paths, schedule scans,
Speaker 2: managed definition updates.
Speaker 1: And you mentioned a clever setting for VMS earlier.
Speaker 2: Yes, the randomized scheduled task times setting in group policy.
Speaker 2: For Defender. This is especially important on hyper v hosts
Speaker 2: or FEEDI environments where you might have tens or hundreds.
Speaker 1: Of vms, oh I randomize.
Speaker 2: If you don't, all those vms might try to run
Speaker 2: their scheduled scan or download updates at exactly the same time,
Speaker 2: say two point zero am. This can absolutely crush the
Speaker 2: host CPU and disc io, making everything grind to a halt.
Speaker 2: Randomizing spreads that load out over a window of time
Speaker 2: maybe an hour or two, so you don't get those
Speaker 2: huge resource spikes.
Speaker 1: That is smart prevents a self inflicted performance disaster and
Speaker 1: beyond updates in malware, just keeping an eye on things.
Speaker 1: Monitoring tools.
Speaker 2: Window Server has a whole suite. You've got the quick
Speaker 2: overview of task manager, deeper dives with resource monitor and
Speaker 2: Performance monitor for tracking CPU memory, disc network usage over time,
Speaker 2: and critically.
Speaker 1: Event Viewer ah the logs.
Speaker 2: Everything gets logged there, system events, application error, security audits.
Speaker 2: But the really powerful part for larger environments is event subscriptions.
Speaker 2: You can configure servers to forward specific events to a
Speaker 2: central collector server, so.
Speaker 1: You don't have to log into fifty servers to check
Speaker 1: their logs exactly.
Speaker 2: You get one consolidated forwarded events log with all your
Speaker 2: important stuff from multiple systems makes monitoring and troubleshooting way
Speaker 2: more efficient.
Speaker 1: Okay, we've covered a lot of ground on traditional server
Speaker 1: roles and virtualization. Let's shift to something newer, more cutting
Speaker 1: edge for server twenty sixteen Windows containers. How are these
Speaker 1: different from hypervvms?
Speaker 2: Fundamentally different approach. Hyper v virtualizes the hardware. Each VM
Speaker 2: gets its own entire operating system, its own kernel drivers,
Speaker 2: it's a full machine simulation. Containers, on the other hand,
Speaker 2: virtualized parts of the operating system.
Speaker 1: Itself, virtualize THEOS. How does that work?
Speaker 2: The key concept is namespace isolation. All the containers running
Speaker 2: on a host actually share the host operating systems kernel,
Speaker 2: but each container gets its own isolated view of things
Speaker 2: like the file system, the registry, network, ports process lists.
Speaker 1: So they think they have their own OS, but they're
Speaker 1: really just using segregated parts of the host OS.
Speaker 2: In essence. Yes, the hosts kernel manages this isolation, only
Speaker 2: showing each container the resource is allocated to it. It's
Speaker 2: much lighter weight than a full VM because you don't
Speaker 2: have that overhead of a separate OS kernel and duplicate
Speaker 2: system files for every single instance.
Speaker 1: Lighter weight means faster startup, more density on a host exactly.
Speaker 2: Containers can often start in seconds compared to minutes for
Speaker 2: a VM, and you can typically run many more containers
Speaker 2: on the same hardware compared to vms. Plus the host
Speaker 2: DOS can enforce resource constraints. You can tell a container
Speaker 2: you only get to use one CPU core, or you're
Speaker 2: limited to five hundred and twelve million bit of RAMS.
Speaker 1: So one noisy container doesn't hog all the resources from
Speaker 1: its neighbors.
Speaker 2: Right ensures fair sharing and predictable performance in multi tenant scenarios.
Speaker 1: Now I heard there were two types of Windows containers
Speaker 1: in server twenty sixteen.
Speaker 2: That's correct, you have Windows Server containers. These provide that
Speaker 2: process and namespace isolation. We just talked about sharing the
Speaker 2: host kernel directly. They're the fastest and.
Speaker 1: Lightest option, okay, and the other type.
Speaker 2: Hyper V containers. These offer an extra layer of isolation.
Speaker 2: Each hyper V container actually runs inside a very minimal,
Speaker 2: highly optimized special purpose virtual machine. Crucially, each container gets
Speaker 2: its own copy of the Windows.
Speaker 1: Kernel AH, so they don't share the host kernel.
Speaker 2: Correct, they still share hardware resources, but the kernel isolation
Speaker 2: is much stronger, almost like a full VM, but still
Speaker 2: much lighter and faster to deploy than a traditional VM.
Speaker 1: Why would you need that extra isolation.
Speaker 2: Maybe you're running untrusted code, or you have strict multi
Speaker 2: tenant security requirements where even kernel level sharing isn't acceptable,
Speaker 2: or perhaps the application inside the container needs a different
Speaker 2: kernel version or patch level than the host. OS. Hyper
Speaker 2: v containers provide that stronger boundary.
Speaker 1: So a spectrum of isolation options and managing all these
Speaker 1: container Docker is the tool for that.
Speaker 2: Docker became the de facto's standard pretty quickly. It's the
Speaker 2: command line tool and engine you use to build, ship
Speaker 2: and run containers. You use Docker commands to download basos
Speaker 2: images from repositories like Docker.
Speaker 1: Hub, which is like an app store for container images.
Speaker 2: Kind of yeah, a huge public registry with official images
Speaker 2: for Windowserver, Core, Nanoserver, Linux distributions, applications. Then you use
Speaker 2: Docker to build your own application layers on top, create
Speaker 2: new images, and then run stop list and manage your
Speaker 2: running containers and networking.
Speaker 1: For containers, how do external users reach an app inside
Speaker 1: a container?
Speaker 2: Docker handles port mapping. You tell docer map port eighty
Speaker 2: on the host machine to port eighty eighty inside this
Speaker 2: web server container. Then traffic hitting the host on port
Speaker 2: eighty gets automatically forwarded to the application inside the container.
Speaker 2: Docker manages all that virtual networking behind the scenes.
Speaker 1: Makes sense, It orchestrates the whole life cycle, it really does.
Speaker 2: It's simplified container usage dramatically.
Speaker 1: Wow, we've covered a ton of ground today. We started
Speaker 1: by just redefining what a server even.
Speaker 2: Is, right, moving beyond just the box, and.
Speaker 1: Then dove into Windows Server twenty sixteen's capabilities. Flexible storage
Speaker 1: with storage spaces and ded up, powerful virtualization with hyper
Speaker 1: v and all its networking tricks.
Speaker 2: Live migration, VM resiliency.
Speaker 1: Robust high availability using NLB and failover clusters including that
Speaker 1: clever cloud witness.
Speaker 2: And proactive maintenance with WSUS and Defender plus smart.
Speaker 1: Monitoring, and finally, the agile world of Windows containers managed
Speaker 1: by Docker. It's really quite an ecosystem.
Speaker 2: It truly is. The amount of engineering that goes into
Speaker 2: making all this work reliably, securely, efficiently. It's pretty incredible,
Speaker 2: all aimed at keeping your digital services running smoothly.
Speaker 1: So thinking about the bigger picture, this invisible work done
Speaker 1: by server operating systems like Windows Server twenty sixteen is
Speaker 1: just becoming more and more critical, isn't it?
Speaker 2: Absolutely? As we rely more on distributed services cloud platforms,
Speaker 2: the intelligence baked into the OS layer is paramount, which
Speaker 2: leads to a thought. Is that line between a server
Speaker 2: and just any other powerful computer becoming kind of blurry?
Speaker 1: Or is it just constantly being redefined? Maybe it's less
Speaker 1: about the label server and more about the capabilities and
Speaker 1: resilience provided by the software wherever it happens to run.
Speaker 2: That's a great way to put it. The function defines it,
Speaker 2: not necessarily the form factor. So for everyone listening, what
Speaker 2: aspect of all this tech sparks your curiosity? What might
Speaker 2: you want to dive deeper into next?
Speaker 1: Definitely something to think about as you navigate our increasingly
Speaker 1: digital world.