After installing KB5001347 Windows Server Backup fails backing up system state (Hyper-V host component and VMs are involved) at least if a Synology NAS device SMB Share is targeted.

The error message(s) in backup management console is/are:
- The mounted backup volume is inaccessible. Please retry the operation.
- The operation ended before completion.

The following error(s) is/are logged in event viewer:
- 517, Backup: The backup operation that started at 'UTC‎TIMESTAMP' has failed with following error code '0x8078004F' (The mounted backup volume is inaccessible. Please retry the operation.). Please review the event details for a solution, and then rerun the backup operation once the issue is resolved.
- 10170, HYPER-V-VMMS: Requester reported unsuccessful backup for the virtual machine 'MACHINENAME'. (Virtual machine ID GUID).

The error is reproducible among all Hyper-V-Server 2016 installations. After uninstalling KB5001347 backup starts working again. After re-installing KB5001347 backup starts failing again.

Hi

We have 8 RDS server, all running Windows server 2016, but after installation of Windows server 2016 update KB4593226, Microsoft print to PDF is not working anymore

When I try to print an document to PDF printer, the printer dialog box says following "Before you can print, you need to sect a printer"

I have try to uninstall the "Microsoft print to PDF" and install it again, but when I try to install it again I get following dialogbox from "Network
printer installation wizard"
Printer driver was not installed

The system cannot find the file specified
It look like Windows doesn't now where to find printer driver after installation of December 2020 update KB45933226

When I uninstall KB45933226, everything is working again, please help ?

/Jan

DNS Policy currently supports split-brain configurations only where the DNS server is authoritative for both zones (eg. respond with IP1 for internal users and IP2 for everyone else).

It would be helpful if DNS Policy also supported split-brain scenarios where the resolver is NOT authoritative for one of the zones. This is useful in cases where the resolvers are separate from the primary DNS servers and the customer wants to specify a different IP address to a subset of clients, or when the primary DNS server is not managed internally but we want to 'overwrite' one or more IP addresses.

There is no security concern because we can already manually create a copy of the authoritative zone, however this approach is undesirable since IP addresses will become stale.

Some methods for implementing this could include:
1) Global and/or zone setting to allow recursion for names that cannot be resolved in local zones
2) Add a "RECURSE" action to Add-DnsServerQueryResolutionPolicy: ALLOW, DENY, IGNORE, RECURSE
3) Change the behaviour of "IGNORE" to recurse when the zone contains no resource records
4) Allow DNS Policy to be created on stub zones or conditional forwarders

Thanks.

Network Location Awareness is very useful feature on desktops. Particularly in the current climate of people taking machines home, having them detect "Public" networks is useful.

However, it is nearly unheard of for a Windows Server to be picked up and taken to an untrusted network. Instead of the benefits of this feature, there are many reasons wherein a server may decide it's in a public network and firewall itself from access. This will, for example, prevent a file server sharing files, or an Exchange server accepting email. If this occurs to Domain Controllers, it will trigger all other servers to consider themselves on a public network and generate effectively an "all servers down" scenario.

A Google search for "network location awareness" leads to no discussion about the feature, and pages and pages of workarounds for a problem that is clearly quite common.

There is a commonly described workaround involving restarting, or delaying the start of the Network Location Awareness service. But thinking about this logically, it's a "workaround" to a problem that should not occur.

This is particularly relevant to a Server Core installation that would never be taken home for use as a desktop, and can be quite difficult to troubleshoot without a UI.

If a Powershell command or registry edit would allow us to just set a server to "always use domain profile", we could improve resilience and remove these sort of issues from occurring, whilst avoiding workarounds of dubious quality.