Hey Everyone. Randy, Premier Field Engineer, here to discuss some lessons learned from working with a recent merger between two corporations. I don’t have enough time or space to go into the details of this major endeavor, so I am going to talk about this experience with a “Top Ten Countdown” style BLOG POST. I’m sure there are many other headaches seen in the field and I would love to hear about them in the comments section. Maybe I can start to consolidate all this into a Wiki about Partnerships and Mergers between two dueling Active Directory environments. Let’s get started:

1. This one being the most important! Never establish multiple trust paths: I have had the same conversation with countless engineers when doing phone support, about setting up both a Forest Trust between the two Forest Roots, and also an External Trust between two child domains in each of the forests. This should never be done under any circumstances. The argument is often “But this is a shortcut trust.” A Shortcut Trust is between two different domains in the same forest. I have also seen arguments where certain applications (here is an example) that are performing logon routines are not able to query a forest, and therefore need a direct trust. There is likely a newer version of the application without this requirement. If there is not an update or competitive product without this requirement, then it is time to do some soul searching on what is more important. The crux of the issue is different technologies providing the trust path between the same domains, each having different characteristics and limitations. One workflow may use the enumeration of trusted domains and hit one of these limitations based on the technology invoked.

2. Beware of CNAME (alias) records in DNS: This is true regardless of traversing a trust, or in the local domain. The behavior of how SPNs are formatted in the client’s request has dramatically changed over various versions of Windows. This article talks about this behavior, although it is not that straight forward about why it is a problem. When accessing a resource using Kerberos Authentication, the client has to construct a Service Principal Name based on the Host Name offering that service. Take a look at the example Below:

Here we have a File Server (FileServ1.adatum.com) hosting a Share (\\SalesReports\Monthly.) In DNS, we configure a Cname record to direct any DNS query for SalesReports.adatum.com, to the physical host of website Fileserv1.adatum.com.

In Windows XP and SMBv1: We would ask the KDC/Domain Controller for CIFS/SalesReports, because that was the hostname supplied in the UNC Path.

In Vista and SMBv2: We would ask the KDC/Domain Controller for CIFS/FileSrv1.adatum.com, because that was the hostname resolved in the DNS CNAME query.

In Windows 8: We once again returned to the original behavior of asking for CIFS/SalesReports, and adding the “NETDOM COMPUTERNAME /ADD” to supply an alternate name that would register the SPN for you.

The recommendation from Microsoft is to avoid CNAME records if at all possible. This will avoid a variety of headaches because you could see unexpected outcomes as you use other network transports like HTTP.

3. Use Fully Qualified Domain Names: When joining a domain, writing logon scripts, or configuring an application setting that requires a computer or domain name, I have just made this a habit ever since about 2003. There are plenty of ways that Windows can overcome flat names, but why not keep it simple wherever you can. By supplying the FQDN, we tell DNS exactly what we want without confusion. Here is a short list of problems you will avoid:

1. Same Host Names exist in multiple domains

2. Time delays having to parse through the domain suffix search order to look for a match

3. Kerberos KDC knowing which realm to forward the ticket request

4. Disjoined Name Spaces or Unorthodox Naming Conventions

The next two items on the list are related to FQDN.

4. Kerberos Forest Search Order: In some situations, flat names may be used and will format the SPN request made by the client as “HTTP/ServerName” (for example) and not include the domain suffix. The domain suffix is important because the user will always go to its local domain’s KDC which uses the domain suffix to identify which Kerberos Realm it should direct the user. There is a GPO setting that can be configured either for the client or the KDC which lists out other realms where it can check for a matching SPN. A configuration that I found useful is to list the Workstation Forest in the KFSO GPO applied to the workstation. This was helpful in a situation where users have been migrated to the new AD Forest, but their workstations have yet to be migrated. Let’s watch this play out in a cartoon entitled “The Adventures of Joey Adatum!”

The beauty of this solution is that there would be no performance impact (as described in the TechNet documentation) because the workstation is just asking its local Forest and would only be relevant if the logged on user was from a different Forest.

5. DFS Namespaces: To continue on the topic of domain suffixes, update DFSN to use DNS FQDN’s. This will ensure that any cross forest usage of DFS Namespaces will resolve correctly. Another important aspect is the Special Names Table generated for the forest. The Special Names Table is a list stored on each Windows client that it gets from the DC. It is a listing of domain names that the DFS client needs to recognize when resolving a UNC path as either a Domain-Based DFSN or a regular Server Name. A Two-Way Forest trust will not give you any problems with populating this table for the partner forest. If you start playing with One-Way, or External Trusts, you might not get the results you are looking for, especially when child domains are involved. You can see the Special Names Table by using “dfsutil /spcinfo” on a client that has the DFS RSAT tools installed. See the example below when running dfsutil /spcinfo on a workstation in Widgets.Adatum.com:

One-Way Trust:

C:\temp>dfsutil /spcinfo

[*][WidgetDC1.widgets.adatum.com*widgets]

[*][widgets.adatum.com]

[-][adatum]

[-][adatum.com]

[-][widgets]

[-][widgets.adatum.com]

Two-Way Trust:

C:\temp>dfsutil /spcinfo

[*][WidgetDC1.widgets.adatum.com*widgets]

[*][widgets.adatum.com]

[-][adatum]

[-][adatum.com]

[-][widgets]

[-][widgets.adatum.com]

[-][Contoso]

[-][Contoso.com]

[-][Asia]

[-][Asia.Contoso.com]

The good news is Windows 8 & 10 clients seem to behave, and I only found this to be an issue with Windows 7 / 2008 systems. This can be a major problem with new SMB Hardening recommendations for \\*\Sysvol and \\*\Netlogon. If you have a One-Way trust and Windows 7 clients with SMB hardening, then they won’t be getting group policy across the forest because Kerberos will fail.

6. Will users log on interactively or via RDP to systems across the Forest Trust? I am including this as a separate line item because it will likely be the biggest headache that you encounter. The two items above on our list are examples of problems you might face. It would be helpful to really think through these situations and see where Network Access would be sufficient.

7. Don’t forget about udp port 389: Firewall configuration is always important when troubleshooting cross forest failures. Make sure all the required ports are open for Active Directory, udp 389 is often forgotten, but very important for DC Discovery operations.

8. Site Affiliation: For optimal performance, we want to make sure that we are choosing resources located near our physical location. I won’t go into detail, because a great BLOG POST was written eight years ago that still reigns true today.

9. Make security policies consistent: Why are domain controllers all located in a single OU? Answer: To make sure they all get the same GPO Security Settings. When we establish a trust between two Active Directories, we are extending our trust boundary beyond the local forest to our partner. You want to pay careful attention to conflicting settings that would break communications. Here is a classic KB article which describes numerous potential conflicts. Make sure you work together on a common security baseline for both AD Forests. If this is going to be a long term relationship, I recommend a solution in place to identify a naming convention for GPOs with sensitive settings and routinely synchronize or compare these GPOs. Some tools that may help in this effort are the Security Compliance Manager (free!), or Advanced Group Policy Manager (requires MDOP license)

10. Be aware of your partner’s vulnerabilities: When you open your doors to a partner environment, you could be exposing yourself to all the threats they encounter. Here are some questions to ask:

1. How do they enforce system health compliance?

2. How do they deliver patching and security updates?

3. Are they running legacy operating systems?

4. What are their Password Policies?

5. How many Domain Admins do they have, and are any of them service accounts?

6. Have they reported security breaches in the past?

Whenever your users traverse the trust, they could be exposed to credential theft. In turn, their users are now your users. Whatever vulnerabilities and compromises they face, are now your problems. You can set up various roadblocks to prevent these issues.

1. Don’t let privileged accounts logon interactively and restrict what they can access over the network. Stay away from Legacy Operating Systems.

2. Consider Security Considerations for Trusts, implement measures like SID Filtering or Selective Trusts.

3. Secure Privileged Access with a Tier Administration Model and other mitigations.

These are just a few examples of considerations. Just keep in mind that this is a major endeavor and should be well planned. Also, think outside of the box. This may be time to consider hosting services in Azure and merging the two forests in Azure AD, while keeping your on premise nice and isolated.

Good Luck,

Randy “Trust me” Turner

Hey Everybody! I am Jose Blasac, a Microsoft Premier Field Engineer, here with my first post on the world famous ASK PFE Platforms blog! I am super excited!

I spend a lot of time working with System Center Configuration Manager and Windows 10. If you have done any work with Config Manager and Windows 10 Servicing, you will have noticed some of the pre-requisites like Heartbeat Discovery and WaaS Deferral GPOs (More on this later).

By default, all Windows 10 systems are discovered as CB or Current Branch. (If you are not familiar with WaaS Concepts like CB or CBB, head over to our WaaS Quick Start Guide)
https://technet.microsoft.com/en-us/itpro/windows/manage/waas-quick-start

Starting with Config Manager 1511 a pair of new attributes have been added to the DDR or the Heartbeat Data Discovery Record of Config Manager Clients. For our purposes, we are concerned with the OS Readiness Branch attribute as highlighted below.

The OS Readiness Branch properties of a Computer Object can display the following values:

• Do not defer upgrades = CB
  
• Defer Upgrades = CBB
  
• LTSB = LTSB
  

So where does the Client discover this information?

As I stated earlier, these attributes are now part of the DDR that is inventoried on Clients and copied up to the Management Point for Processing by the Primary Site. We can trace these activities on the client side via ConfigMgr Log files. The Client logs Discovery actions in the InventoryAgent.log found in %windir%\CCM\Logs folder. 

After manually initiating a DDR cycle let’s follow the action. If we drill down through the InventoryAgent.log to see what items were discovered and inventoried, we can see the following WMI query with a particular property of Interest! 

So, what is the OSBranch property all about and what values are we potentially looking for? If we launch the good old Wbemtest utility, we can test this WMI query for ourselves!
Right Click on Start, Run, Type in Wbemtest and Launch the Utility. Hit Connect and Attach to the Root\ccm\invagt namespace. We can take part of the query above to peek into the OSBranch Property. 

As you can see above we have an integer value of 1. This system is considered a CBB client.
The OSBranch Property has the following possible integer values:

• Current Branch or CB = 0
  
• Current Branch for Business or CBB = 1
  
• Long Term Servicing Branch or LTSB = 2
  

As we continue to piece this together, what is the Client Discovery routine looking for to decide what value to set the OSBranch Property to? Now I happened to have read the documentation on configuring Windows Update for Business which is here.
https://technet.microsoft.com/en-us/itpro/windows/manage/waas-configure-wufb

So technically I already know what Registry Keys need to be set. (I am doing all my testing in this blog on Windows 10 1607)
If we scroll down the page to the section titled “Configure Devices for Current Branch (CB) or Current Branch for Business (CBB) we can see the Release branch policies and how to configure them for either Windows 10 1607 or Windows 10 1511. Here is a snippet of that Table. 

With that said we still have the ability to trace this for ourselves and observe the system behavior. Let’s resort to one of my favorites tools, Process Monitor. Chances are you have used this in the past but just in case you can go over to www.sysinternals.com and grab the it!

Prior to initiating a DDR discovery cycle I will launch Process Monitor. The DDR cycle runs quickly so I will pause the trace after approx. 30 seconds. Then I begin to search for key terms. In this case I used to the term “Branch”. 

Bingo!! The first hit takes us right to the relevant Registry key. 

We can see the RegQuery being performed by the WMI Provider host process but let’s dig deeper and see who is initiating the actions.
Double click on the Highlighted Line item and pull up the Event Properties Dialog box. 

Let’s go to the Stack tab to view this Threads Stack activity. Without getting too Nerdy we can see some Config Manager activity once we walk up the Stack. 

The ddrprov.dll belongs to the Config Manager Client DDR Provider as detailed below. 

Phewww, ok so now what? Knowing how Config Manager Discovers and identifies WaaS in Windows 10 can be very helpful once we start to play with things like Windows 10 Servicing Plans or trying to make sense of the Servicing Dashboard. Etc
We can create collections based on some of these Attributes and create Deployment ‘Rings’. For example, you could create collections based on OS Build or OS Readiness Branch. 

Some of the possible integer values when setting up your Query. 

We could also run SQL reports and queries against the Config Manager database to identify systems. The SQL view of interest is v_R_System. This contains the attributes like OS Build and OS Readiness Branch.
Here is an example query and result: 

As you can see the Branch value is also an integer in the Database. As we should have all mastered by now, Current Branch or CB is 0 and so on and on….

Well, I hope you have enjoyed this little exercise on identifying WaaS systems in your environment using System Center Configuration Manager.

Till next time!!

Jose Blasac

Hi everyone, my name is Nicholas Jones, System Center Configuration Manager Premier Field Engineer, and I’d like to share some work I’ve been doing on building and capturing images. You might be a little surprised to see a blog post on building Windows 7 images on an official Microsoft blog. Make no mistake: we recommend our customers switch to Windows 10 to take advantage of huge advancements in security.

While we advise our customers to switch to our most secure platform, Windows 10, we realize many of you must support and deploy Windows 7 while your migration projects are underway. If that is the case, we want to ensure you’re deploying Windows 7 with all needed security updates.

Second to the security conversation, there is potential to save your company some serious man hours. Imagine your company is deploying roughly 100 Windows 7 instances per week. Now imagine if we were installing dozens of updates, on the fly, during or after that process. That could easily add 30 minutes to the deployment. Multiply that by 100, and well, you can do the math…

I’ll be using System Center Configuration Manager for this tutorial, mainly because that’s my specialty, but these instructions can be adapted for other products. I realize many people use MDT to build their images, so that they can customize the default user profile and maybe for other reasons. The goal of this exercise is to have a Windows 7 image that can be deployed which minimizes, if not completed eliminates, updates required by Microsoft Update. This article does assume that you have a working knowledge of Operating System Deployment in Configuration Manager, so I won’t be covering things like content distribution and creating task sequence deployments.

Sounds simple, right? Let’s get started.

First, we will need a copy of Windows 7 SP1. You can grab the ISO from your Volume Licensing Site. Make sure you have the SP1 copy and not RTM. In the Configuration Manager console, we will need to copy the install.wim file from the ISO to our source share, like in the screenshot below. The exact path you use will vary on your environment.

We’ll import that WIM to Configuration Manager, and name it something like “Window 7 SP1 x86 – Original”. Any name is fine, but make sure it’s obvious this image is only used for building and capturing reference images. You wouldn’t want to slip this in to a production task sequence.

After our image imports, we can move on to creating the task sequence. Go through the steps of creating a basic build and capture task sequence and make sure to reference the image we just imported. It will look like this when you’re done:

So, why can’t we stop here? Because there have been so many dramatic changes to Windows 7 over the years, it’s going to take a few special steps to make sure our build and capture actually works. The Install Updates step simply will not install the hundreds of updates you would need. On top of that, the Windows Update Agent that is built in to the original Windows 7 SP1 media may not work reliably. There is also the change to Windows servicing that happened late last year and the convenience update we released, so we’re going to use those to our advantage.

Here is the complete task sequence (ignore the disabled Capture section):

Let’s talk about the logic here and walk through the steps.

The first custom section you’ll notice is called “Install standalone updates”. The goal here is to get the convenience update installed, and to get a decently modern Windows Update Agent installed. The convenience update requires a servicing stack update, so we’re installing that first.

…next is the convenience update.

…and finally, we have the March 2016 WUA. (If you come across a newer WUA, use that instead.) You’ll want to follow this with a restart.

You’ll also notice that I’m installing KB3177467 at the end of this group. Due to a known issue when installing this update with other updates, I really did not have much success with this project until I separated this update from the others.

So far, things are straightforward. What comes next is a little odd and specific to Configuration Manager, so hopefully I can explain this well enough. I wanted to create two groups of updates to install during this build and capture. I want one group to go first, then a second group to be evaluated last. The logic behind this is to apply whichever Security Monthly Quality update is available first, then apply all of the remaining updates that are needed.

I create two Software Update Groups (SUG) for this.

“Windows 7 Build Required” contains the latest Security Monthly Quality update (January 2017 at the time of this writing). I want this update to apply before any other updates, so it’s deployed to my build collection as required.

“Windows 7 Build” consists of all the remaining updates that the image needs, post convenience update and Security Monthly Quality update. I want to apply these last, so I deploy it as available.

Back to the task sequence:

Install Updates 1 and 2 are set to only install required updates. This ensures we’re only looking at the small update group which contains the monthly update. I repeat this step twice, just in case I add some updates to that group later, which are prerequisites for other updates in the same group. If you’re only installing the monthly rollup, you can remove the second group of ‘Install Update, Set TS Variable, Restart Computer’.

On the third through fifth steps, I’m checking for all software updates. This allows the process to check the remaining updates after the monthly rollup has been installed.

I repeat this three times to catch all of the updates. The Set Task Sequence Variable steps set SMSTSWaitForSecondReboot to 600, just in case I’m running into a Configuration Manager specific problem with updates requiring two restarts.

Identifying the updates that are needed in that second group is tough. You could run through this process with only the ‘required’ updates, then perform a scan and see what is left. That is the method I used. It’s tedious, but it works. If you have a better solution, let me know in the comments.

Wrapping up the task sequence, I have an additional group for any updates that didn’t install previously. This could be due to the update not being released to the WSUS channel, or it could just be problematic installing with other updates. These are the ones I came up with. If you find more, you could add them to this group.

They simply call the WUSA command to install the updates, followed by a restart, sysprep, and image capture.

Remember, the goal of this blog was simply to be able to create a Windows 7 image that would minimize or eliminate any updates needed during or immediately after deployment. There could still be hotfixes or other updates that you should install.

If you have any success stories, suggestions, or other comments that relate to this writing, please share them. Also, please let me know if you find updates that were missed. I hope to keep this article updated over time.

Thanks!

Nicholas Jones

Hi all, this is Kevin Kelling and I’m a PFE with Microsoft focused on both Hyper-V and Azure.  Today I’d like to talk about the performance of Linux workloads on both Hyper-V and Azure. Every now and then we are asked how well Linux performs on Hyper-V.  We’ve done extensive testing and most of the time it runs quite well, but we’ve found a few cases, where some tuning can make all the difference.

I recently worked on an issue where a Linux application on Hyper-V (Windows Server 2016) was showing benchmarks of between 30-35% slower than other hypervisors. We instinctively felt something was wrong, so we rolled up our sleeves and got to work.

CHALLENGE ACCEPTED!

After some effort from our outstanding product engineering team, we found that this gap was completely eliminated by tuning some settings in the BIOS, tweaking some Linux kernel parameters, and keeping the in-guest tools current.

No changes were made to the Windows Server or Hyper-V configuration – just BIOS settings, and some changes within the Linux guest VMs. In other words, Hyper-V delivers great performance, but sometimes we need to tune the environment to take full advantage of it.

What changes made up for what initially was a significant difference in performance? Let’s go take a look!

TURN THOSE C-STATES OFF!

Many systems have power management profiles in the BIOS, and while many environments correctly have this set to “performance”, many systems will still have additional options for individual C-states.  If you want a primer on what a C-state is, there’s a good article here from Intel, but basically it’s a power management method.

Hyper-V tries to aggressively leverage C-states to reduce power consumption, but if you want the best possible CPU performance on your host servers, turn it all off!

In this case, we observed a 15% performance improvement after disabling all C-states in the host server’s BIOS.

Upgrade Linux Integration Services (LIS)

Linux Integration Tools consists of optimized synthetic device drivers and other “virtualization helpers” that go into the guest OS.  Windows servers have integration services built in and get can updates via Windows Update. Linux is similar in that the various distributions will build LIS into their images, and — depending on what version you are running — updates are distributed through their respective patch channels.

LIS 4.1.3 was released in December of 2016 (download here) and we found that simply updating to this version of LIS there was a 10% performance increase. The performance difference of course will vary based on the application, the version of Linux and the current version of the tools, but in this case the difference was quite significant.

A few notes here — some Linux distributions will not support LIS unless it is released through their patch distribution. Before you manually install LIS, make sure you understand if there are any support implications from your Linux vendor.

On the topic of LIS one final important point to keep in mind is that it makes a big difference what version of Linux you are running, as not all features are supported on all versions of Linux. If you visit the Hyper-V Linux support page, you will see sections for RHEL/CentOS, Debian, Oracle, Ubuntu, SUSE and FreeBSD.  In each of these sections you can find details on which Hyper-V features are supported in which Linux versions.

Bottom line again, is that in this case, simply upgrading LIS to the current version of 4.1.3 delivered a 10% performance improvement.

Set the Linux Clock Source

Let’s say you didn’t want to upgrade to the latest LIS.  You can still capture much of the performance improvement here simply by tuning the Linux clock.

Changing the Linux kernel’s clock source to “tsc” which stands for “Time Stamp Counter” resulted in a performance improvement of 6%.  This particular application had a lot of context switches and made heavy use of clocks and timers, so your mileage may vary here.

A bit of information on this parameter is available here.

How Many CPUs?

Linux kernels have an optional parameter where you limit the number of possible CPUs by setting the “possible_cpus” kernel parameter.  For example, if you have 8 virtual CPUs in the guest, edit the kernel parameters to include “possible_cpus = 8”. By setting this parameter, additional overhead processing was removed from the Linux CPU scheduler.

In this application, a performance improvement of 2% was observed after applying this setting.

CPU Load Balancing

Hyper-V presents a somewhat different view of the hardware to the guest OS than some other hypervisors do, in regard to how the L3 cache is presented. As a result, the Linux scheduler was not being sufficiently aggressive in scheduling the workload and some vCPUs were going into an idle state when they shouldn’t have.

By writing a simple shell script to run at boot, the Linux CPU scheduler used all of the vCPUs more efficiently, resulting in a 6% performance improvement for this application.

The Bottom Line

IT is often complicated.  There’s so many distros, Linux versions and workload patterns generated by applications and other variables to consider — your mileage may vary.

But what at first appeared to be a big difference in performance, was completely eliminated by making absolutely no change to the Windows Server operating system – only changes in the BIOS (hardware) and within the Linux guest were needed to eliminate the performance difference.

In other words, you can rest assured that Hyper-V 2016 is capable of delivering strong performance for Linux workloads. Furthermore, you can expect some improvements in future updates to LIS (Linux Integration Services) to automatically exploit some of these tweaks, with the benefits extending to Linux workloads on not just Hyper-V, but to Linux on Azure as well.

If you are concerned that your Linux workloads may be running slower than they could be on Hyper-V check these three basic things:

• Disable C-States in BIOS
• Upgrade to current version of LIS (If not an option, change clock source to “tsc”)
• Set “maximum_cpus” in the Linux kernel

And if you suspect a problem with idle cores not being utilized, you may be able to further improve performance by tweaking the Linux scheduler (guest OS).

For one application, these above steps resulted in a performance improvement of over 30%.

So if you have any concerns about Linux performance in Hyper-V, you can have the confidence that Hyper-V and Azure are capable of delivering strong performance.  There may be cases where you may want to tweak some guest level settings in the Linux OS in order to achieve maximum performance.

Hello, Dave Guenthner back again with a discussion about Office 365 ProPlus. In February of 2016 I wrote a blog entry about how enterprise customers can service\patch Office 365 ProPlus with System Center Configuration Manager (ConfigMgr) I’ve spoken to many customers about this feature but only recently have customers upgraded from ConfigMgr 2007 and 2012 R2 to ConfigMgr Current Branch to use feature in production. The intention of the blog is talk about how to troubleshoot this feature using a recent case as reference. Basic documentation and requirements are posted here on TechNet. The reality is, each of us learns more when things don’t work than when they do. My case started with the following question…

“Hey Microsoft, we’re not seeing any updates for Office 365 ProPlus in Software Center?”

Checklist for SCCM:

1. Verify Office 365 Client product is selected from Products within Software Update Point Component Properties

2. Synchronize updates, verify Office 365 Client Updates exist within Software Updates node.

3. Create Automatic Deployment Rule (ADR) to download and deploy updates to collection of machines. In my case, customer has clients on First Release for Deferred and Deferred. Since updates for First Release channels can occur at any time, ADR is perfect to automate process of keeping updates current. (*Assume you know how to create ADR) Search criteria (example below) will constrain download only to two channels appropriate for this customer. Run ADR and verify content has been downloaded and distributed to deployment points. Important to note, customers should have ~10% of clients on a validation channel such as First Release Deferred and ~90% on Deferred Channel. In this way, ADR is automating download of content but SysAdmin is controlling schedule of deployment.

4. Verify Software Update Group created is deployed to desired collection. In example, ADR is deployed to All Desktop and Server Clients.

Checklist for Client:

1. Install a N-1 version of Office 365 Client. By intentionally installing one month old version we can be confident updates will be applicable. As of this writing, N-1 for deferred channel is 6965.2117 and latest version is 7369.2118. Install Office 365 Client using Office Deployment Tool using sample unattend. (Assume you know how to install Office 365 Client)

2. System Center Configuration Manager references CDNBaseUrl to understand which channel is in scope for Office 365 Client. In this case, the GUID below is “Deferred Channel”, since our ADR included this channel we’re in good shape. You can use the RIOScan tool located here to provide a simple summary report to tell you what is installed and how its configured.

HKLM\SOFTWARE\Microsoft\Office\ClickToRun\Configuration

“CDNBaseUrl”=http://officecdn.microsoft.com/pr/7ffbc6bf-bc32-4f92-8982-f9dd17fd3114

3. System Center Configuration Manager in its applicability check requires Office COM interface to be enabled to help broker communication between Office and ConfigMgr. Typically, customers have already deployed some Office 365 Clients and want to turn this functionality on. The Software Updates client setting show below is used to enable this:

Alternatively, this can be accomplished via domain policy using Office 2016 ADMX file.

You can verify GPO is working by validating existence of following key. When service Microsoft Office Click-to-Run starts it will check for this value and register class to enable COM interface.

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\office\16.0\common\officeupdate

“officemgmtcom”=dword:00000001

4. From control panel, launch Configuration Manager Properties applet and select Software Updates Deployment Evaluation Cycle, click Run Now.

“Hey Microsoft, we checked and double checked all steps and still nothing is happening?”

5. Verify COM interface is registered. It should be, if you enabled it via one of the methods above. You can do this by verifying existence of following registry key on the client.

[HKEY_CLASSES_ROOT\CLSID\{B7F1785F-D69B-46F1-92FC-D2DE9C994F13}\InProcServer32]

@=”C:\\Program Files\\Common Files\\Microsoft Shared\\ClickToRun\\OfficeC2RCom.dll”

“Hey Microsoft, this key doesn’t exist!?”

This is the break we were looking for.

We know if OfficeMgmtCOM is present, Microsoft Office Click-to-Run service will register .dll and enable COM interface. This is not happening in customer environment. Why? Using Process Monitor from Sysinternals site we can take a trace of restarting Microsoft Office Click-to-Run service and stop trace once service has started. One of the features I like is called count occurrences. I immediately saw a smaller number of Access Denied entries relating to registration of .dll in question. Double clicking on the occurrence count will automatically open trace filtering to operation, in our case show all Access Denied.

With this information, we could see McAfee DLP Agent or fcag.exe and with this evidence, make case to disable McAfee Access Protection and restart Office Click-to-Run service. The COM interface key was created and Software Update Deployment Scan finally showed update as applicable in Software Center. Security software and filter drivers are intrusive by design. In this case, customer can follow-up with this vendor and make appropriate tuning change. By taking 3^rd party security software out of the picture, we allowed the COM interface to succeed and Configuration Manager to deem client in scope and advertise update.

Summary

I hope this blog provides a helpful checklist to accelerate and potentially resolve any native patching activities with SCCM and Office 365 ProPlus.

Dave Guenthner

SEO Key words:

C2R, Click-To-Run, Click2Run, Office, SCCM, patch, patching, OfficeMgmtCOM, native, Office 365 Client Update, Office 365 ProPlus

Hi, Mark Rowe here, and I am the creator of Augmented Living, a Developer/Architect for Microsoft’s Modern Applications Solution Center as a senior consultant, and a long-time Microsoft fanboy and blogger.

One of the most hit aspects of security is RDP on the default ports with poor password governance.
People are busy, we all are.
As previously seen on the web, open VNC and RDP ports are not, shall we say, uncommon. For example, ‘VNC Roulette‘ last year was a real eye opener.

So, lock it down, right? We all know a username of “admin” and a password of “password” can only keep your kids and the neighbors from getting into your router (maybe). It doesn’t do much good against attacks on RDP sessions with actual hackers doing the attacks.

So, what do we do? We do more. Time is, as they say, ‘a wastin’, so Let’s get it started.

Note: In this post, we assume you have already setup a virtual machine in ARM in Azure with Remote Desktop Protocol already working on the default IP and port (3389).

Part 1: Create Load Balancer

-“Ok Done! We are with you but what is with all the tomfoolery! What is this magic you speak of?”

The magic comes in with the Load Balancer. First things first, let’s create that.

Add New Load Balancer.

Give the Load balancer a public IP. This will allow it to be seen on the “interwebs”.

Name the IP address and make it static. (Unless you want Dynamic, but you will need to get your Load Balancers IP when it changes.)

We then make sure everything is properly assigned and set the Resource Group to the same one as the Virtual Machine.

Open the Load Balancer you just created.

Add New Inbound Nat Rule to the Load balancer.

-“Hey this isn’t magic or gnomes! I set this up in my router in the 90’s, you know back when IRC was cool and my email address ended in compuserve”.

You got me, this is just like that.

Figure out the Port you want to connect to on the external Load Balancer

Forward that to 3389 internally.

Then set a NAT Rule you can point to an availability set, or just a single VM.

This should make it so you can reach the Load balancers IP:PORT and get into RDP.

*Port would be something like 4000 or 10001. If your IP were 169.0.0.1. Then your RDP line would read 169.0.0.1:4000 or 169.0.0.1: 10001. Those would translate to the 3389 port internally and still connect you to the VM via RDP.

– For all you kids raising your hands out there. Yes 169. addresses usually mean no DHCP could be contacted and that IP should never happen. – Overachievers!

Any other ports that need to make it through here you can also set up 1 rule per. HTTP, HTTPS etc. You can keep the PORTS the same if you just want a pass through. You can keep them or NAT translate them.

Part 2: Removing the Public IP from VM.

Hold my ‘coffee’. We’ve got this, and if not, there is always support. Right?

“Wait, are you selling support hours? ”

You will never know, or maybe you will in 5.

Go to your Virtual machine, click network interfaces. Then double-click on the record with NAME -PUBLIC IP ADDRESS

Click on IPCONFIGURATION then double-click the appropriate Name for the configuration.

Now disable the public IP.

Click save.

Your traffic will now be forced to go through load balancer where you can change IP’s etc and the default 3389 port should no longer be accessible externally.

NOTE: Your Network Security Group will not change, it will still need access to ALL on 3389 if you wish to connect from everywhere.

Part 3: Don’t like only having an IP address?

• “My phone keeps all my numbers in it, if I can’t remember those… How about a name for this monstrosity?”

Easy Peasy, well easy as a few UI clicks. Back to the Portal!

Select your Virtual machines from the Virtual machine menu.

Double-click under Public IP Address/DNS name label

Set the DNS Name in the Textbox. This will give the Load Balancer Endpoint that DNS location.

You should now be able to get to your VM through the LB DNS Name!

NOTE: Security groups are still required on your VM or your subnet in order for data to pass through.

Thanks again for all the work Matt Garing and Sumeet Kumar in helping hash this out.

Questions? (About this article)

Mark Rowe Mark.Rowe@Microsoft.com

***This post was written by Ralph Kyttle, PFE, and back linked to the original post. The original post can be found at: https://blogs.technet.microsoft.com/ralphkyttle/2017/03/21/introducing-dscea/

Hello, World!

I am incredibly excited to announce the open source release of DSC Environment Analyzer (DSCEA), a PowerShell module that uses the declarative nature of Desired State Configuration to scan systems in an environment against a defined reference MOF file and generate compliance reports as to whether systems match the desired configuration.

DSCEA includes a customizable reporting engine that can provide reports on overall compliance and details on any DSC resource found to be non-compliant.  DSCEA utilizes the DSC processing engine and DSC resources to audit and report on the existing configuration of machines in an environment.

By using PowerShell Desired State Configuration at its core, DSCEA obtains some unique advantages. Most notably, by defining the desired configuration state using DSC, an admin can benefit from using the same work to both scan for compliance and then correct items that were found to be non-compliant. Building an audit file in DSC can help ease remediations, and in some cases it can be as simple as applying the same MOF file that was used to scan an environment onto systems to correct drift and bring things into the desired state.

DSCEA is hosted at https://github.com/Microsoft/DSCEA and can be downloaded from the PowerShell Gallery.

DSCEA documentation is hosted at https://microsoft.github.io/DSCEA

So, now that DSCEA is available, what does that mean for you?

DSCEA’s primary use case is to verify that your systems are actually configured the way you want them to be.

Real world examples of how DSCEA can be used include

• Verifying a single setting, for example if a registry key is set appropriately across your entire environment

• Auditing your systems to ensure that they meet the base level system configuration settings that are required to be a part of your environment
• Scanning the systems in your environment against all of the items that make up your organization’s security baseline
• Verifying that settings configured via Group Policy are being applied correctly to the systems in your environment
• Verifying settings configured on Windows Server 2016 Nano servers (which do not support Group Policy)
• Let’s take a look at the first example, to see how DSCEA can be used to verify that certain registry keys are set correctly on a group of systems in an environment.

  First, you will need to install the DSCEA PowerShell module onto the computer that will act as your management system from where you will execute the scan from.  Click here for instructions on installing the DSCEA module.

  Next, you need to create a DSC configuration that defines the desired state you would like to scan for.  Here is an example that defines a desired state for the security related crashonaudit registry key.

  configuration DSCEARegistryTest1 {
      param([string[]]$ComputerName='localhost')
  
      Import-DscResource -ModuleName PSDesiredStateConfiguration
  
      Node $ComputerName {
  
          Registry 'CrashOnAuditFail' {
              Ensure    = 'Present'
              Key       = 'HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa'
              ValueName = 'crashonauditfail'
              ValueType = 'Dword'
              ValueData = '1'
          }
  
      }
  }
  
  DSCEARegistryTest1 -OutputPath .\

  view raw DSCEARegistryTest1.ps1 hosted with by GitHub

  Run the DSCEARegistryTest1.ps1 file, which creates an output file called localhost.mof in your current directory which you will then use to scan systems in your environment.

  Click here for examples on how to execute a DSCEA scan.  One example is included below.

  Scan multiple systems for compliance to settings defined within a localhost.mof file located in your current directory

  PS C:\> Start-DSCEAscan -MofFile .\localhost.mof -ComputerName dsctest-1, dsctest-2, dsctest-3

  This command executes a DSCEA scan against 3 remote systems, dsctest-1, dsctest-2 and dsctest-3 using a locally defined MOF file that exists in the current directory. This MOF file specifies the settings to check for during the scan. Start-DSCEAscan returns a XML results file containing raw data that can be used with other functions, such as Get-DSCEAreport to create reports with consumable information.

  Generate HTML Reports based on scan results – System Compliance

  Once you have completed a scan, you will want to generate reports.  Click here for instructions on creating HTML based reports with DSCEA.  Two examples are included below.

  PS C:\Users\username\Documents\DSCEA> Get-DSCEAreport -Overall

  This command is executed from a directory that contains DSCEA scan result XML files. It generates a report of overall system compliance, and will mark a system as non-compliant if it does not fully match the desired configuration.

  Example HTML Report #1

  
  Next we will use Get-DSCEAreport to generate a report showing all non-compliant items that were detected.

  PS C:\Users\username\Documents\DSCEA> Get-DSCEAreport -Detailed

  This command is executed from a directory that contains DSCEA scan result XML files. It generates a report containing a list of all items that were found to be non-compliant. If all systems that are scanned are found to be compliant, this report will show no results.

  Example HTML Report #2

  Feeling creative?  DSCEA XML data can be converted into CSV, for use with other tools like PowerBI

  This post is just the first of many, as we will continue to explore the ways you can use DSCEA in your environment to verify that your systems are actually configured the way you want them to be.

  DSCEA is an open source solution hosted on GitHub.  We look forward to your feedback and contributions!

Hi Diddly Doodly readers. Michael Rendino here again with a follow up to my “Basic Network Capture Methods” blog, this time to give some best practices on network capture collection when troubleshooting. As you may have guessed, one of my favorite tools, due to my years in networking support, is the network capture. It can provide a plethora of information about what exactly was transpiring when systems were trying (and possibly failing) to communicate. I don’t really concern myself with the tool used, be it Network Monitor, Wireshark, Message Analyzer, Sniffer or any other tool. My biggest point to stress is what I mentioned previously – it shows the communication on the network. The important point to get from that is that collecting a trace from a single point doesn’t provide the full picture. While I will take a single-sided trace over no trace at all, the best scenario is to get it from all points involved in the transaction. With something like SharePoint, this could be a number of machines – the client running the browser, the web front end, the SQL back end and then multiple domain controllers. It sounds like a daunting task to get the captures from every location, but I would rather have too much data rather than too little. To add to that point, please don’t apply a capture filter unless absolutely necessary! By only capturing data between two select points, you could be omitting a critical piece of information.

Following is a perfect example of both of these points. I was engaged to troubleshoot an issue that was described as a problem with a SharePoint web front end talking to the SQL server. I got the captures from the two servers, which fortunately were not filtered. If I just went on the problem description, I would typically have opened the capture from the SQL box, applied the ipv4.address==Web Front End IP (ipv4 because I was using Network Monitor – it would be ip.addr== for you Wireshark fans) to locate the traffic from that box. In fact, I did that to start and saw that all traffic to and from the WFE appeared completely normal.

9873    9:37:54 AM     WFE    49346 (0xC0C2)    SQL    1433 (0x599)    TCP    TCP:Flags=…A…., PayloadLen=0, Seq=3198716784, Ack=438404416, Win=510

10093    9:37:55 AM     WFE    49346 (0xC0C2)    SQL    1433 (0x599)    TDS    TDS:RPCRequest, SPID = 0, PacketID = 1, Flags=…AP…, PayloadLen=201, Seq=3198716784 – 3198716985, Ack=438404416, Win=510

10094    9:37:55 AM     SQL    1433 (0x599)    WFE    49346 (0xC0C2)    TDS    TDS:Response, SPID = 117, PacketID = 1, Flags=…AP…, SrcPort=1433, DstPort=49346, PayloadLen=61, Seq=438404416 – 438404477, Ack=3198716985, Win=255

10188    9:37:55 AM     WFE    49346 (0xC0C2)    SQL    1433 (0x599)    TCP    TCP:Flags=…A…., PayloadLen=0, Seq=3198716985, Ack=438404477, Win=509

To me, it looked like clean SQL traffic, moving quickly and without errors. All good so I needed to look elsewhere. To move on, it’s important to know what other types of things will happen when using SharePoint. Other than the SQL traffic, the WFE will also have to communicate with the client, perform name resolution and communicate with a domain controller. I first applied the filter “dns or nbtns” (Again, this was Network Monitor, although I typically use multiple tools for my analysis) and again, everything looked “clean.” I then moved on to examine the authentication traffic. I applied the filter “Kerberosv5” and lo and behold, the issue jumped right out to me. Appearing over and over in the trace was this:

97    9:38:46 AM     0.0000000    WFE    52882 (0xCE92)    DC    88 (0x58)    TCP    TCP:Flags=……S., SrcPort=52882, DstPort=Kerberos(88), PayloadLen=0, Seq=2542638417, Ack=0, Win=8192 ( Negotiating scale factor 0x8 ) = 8192

98    9:38:46 AM     0.0004965    DC    88 (0x58)    WFE    52882 (0xCE92)    TCP    TCP:Flags=…A..S., SrcPort=Kerberos(88), DstPort=52882, PayloadLen=0, Seq=4098142762, Ack=2542638418, Win=65535 ( Negotiated scale factor 0x1 ) = 131070

99    9:38:46 AM     0.0000200    WFE    52882 (0xCE92)    DC    88 (0x58)    TCP    TCP:Flags=…A…., SrcPort=52882, DstPort=Kerberos(88), PayloadLen=0, Seq=2542638418, Ack=4098142763, Win=513 (scale factor 0x8) = 131328

100    9:38:46 AM     0.0000599    WFE    52882 (0xCE92)    DC    88 (0x58)    KerberosV5    KerberosV5:AS Request Cname: farmsvc Realm: CONTOSO.COM Sname: krbtgt/CONTOSO.COM

102    9:38:46 AM     0.0022497    DC    88 (0x58)    WFE    52882 (0xCE92)    KerberosV5    KerberosV5:KRB_ERROR – KDC_ERR_CLIENT_REVOKED (18)

KRB_ERROR – KDC_ERR_CLIENT_REVOKED means that the client account has been locked out. We checked active directory and sure enough, the account used for the WFE service was locked. We then learned that they had recently changed the password for that service account, which resulted in said lockout. One thing to note about Network Monitor (and you can do this with Wireshark, as well) is that I actually had all Kerberos traffic highlighted in green so it stood out quickly.

So what did we learn? We know that if the trace had just been taken from the SQL server, I wouldn’t have found the issue. We also know that if the WFE trace had been filtered to just include SQL traffic or SQL and client traffic, I wouldn’t have found the issue. Remember, more is better! Even if I get gigabytes of captures, I can always parse them or break them into smaller, bite-sized (no pun intended) chunks for faster filtering. Happy tracing!

Hi this is Michael from the PMC PFE Team, I recently helped a customer during the implementation of their Windows Server 2016 systems.

When checking the Event viewer, we spotted a well-known Event ID:

Log Name:      Application

Source:        SceCli

Date:          08.03.2017 17:49:21

Event ID:      1202

Task Category: None

Level:         Warning

Keywords:      Classic

User:          N/A

Computer:      test2016.mydomain.com

Description:

Security policies were propagated with warning. 0x534 : No mapping between account names and security IDs was done.

Advanced help for this problem is available on http://support.microsoft.com. Query for “troubleshooting 1202 events”.

Error 0x534 occurs when a user account in one or more Group Policy objects (GPOs) could not be resolved to a SID.  This error is possibly caused by a mistyped or deleted user account referenced in either the User Rights or Restricted Groups branch of a GPO.  To resolve this event, contact an administrator in the domain to perform the following actions:

1. Identify accounts that could not be resolved to a SID:
   1. From the command prompt, type: FIND /I “Cannot find”  %SYSTEMROOT%\Security\Logs\winlogon.log
   2. The string following “Cannot find” in the FIND output identifies the problem account names.
   3. Example: Cannot find JohnDough.
   4. In this case, the SID for username “JohnDough” could not be determined. This most likely occurs because the account was deleted, renamed, or is spelled differently (e.g. “JohnDoe”).

1. Use RSoP to identify the specific User Rights, Restricted Groups, and Source GPOs that contain the problem accounts:
   1. Start -> Run -> RSoP.msc
   2. Review the results for Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment and Computer Configuration\Windows Settings\Security Settings\Local Policies\Restricted Groups for any errors flagged with a red X.
   3. For any User Right or Restricted Group marked with a red X, the corresponding GPO that contains the problem policy setting is listed under the column entitled “Source GPO”. Note the specific User Rights, Restricted Groups and containing Source GPOs that are generating errors.

1. Remove unresolved accounts from Group Policy
   1. Start -> Run -> MMC.EXE
   2. From the File menu select “Add/Remove Snap-in…”
   3. From the “Add/Remove Snap-in” dialog box select “Add…”
   4. In the “Add Standalone Snap-in” dialog box select “Group Policy” and click “Add”
   5. In the “Select Group Policy Object” dialog box click the “Browse” button.
   6. On the “Browse for a Group Policy Object” dialog box choose the “All” tab
   7. For each source GPO identified in step 2, correct the specific User Rights or Restricted Groups that were flagged with a red X in step 2. These User Rights or Restricted Groups can be corrected by removing or correcting any references to the problem accounts that were identified in step 1.

So, okay Event 1202 Sid-to-Name mapping issue. Sure enough there was some security principal in either one of the settings or at the delegation tab on one of the policies which couldn’t get resolved.

So let’s have a look at the Winlogon.log as called out in the event description. We went to %SYSTEMROOT%\Security\Logs\ and then “Dude, where’s the Winlogon.log!”

We quickly checked if the path may have changed in Server 2016 but couldn’t find the log in any other directory. Then we checked how this was enabled / disabled on earlier OS versions.

https://msdn.microsoft.com/de-de/library/cc775423(v=ws.10).aspx

HKLM\Software\Microsoft\WindowsNT\CurrentVersion\Winlogon\GPExtensions\{827D319E-6EAC-11D2-A4EA-00C04F79F83A}

Key name: ExtensionDebugLevel
Typ: DWORD
Data: 0x2

Okay, so it is not enabled by default on Windows 10 and Server 2016. We enabled the debug log but still after a “gpupdate / force” and a reboot NO winlogon.log file was present. What’s wrong? Well actually nothing….

Here’s why…

We are talking about a CSE (Client side extension) which is repented by that GUID “{827D319E-6EAC-11D2-A4EA-00C04F79F83A}” ; We did a change in the registry which is only triggers when the CSE is run the next time…. But when there are NO changes to the GPO why should the CSE re-run the respective policy? Exactly,…there is no reason. This has always been the case, the code apparently didn’t change since 2008 but the log just happens to be enabled by default.

So, dude what do we have to do to get the Winlogon.log file back?

There are a few methods available and I’m listing them in the preferred order of applicability:

1. Use the NoGPOListChanges = 0
   1. This triggers the CSE to re-evaluate and trigger the policy even though there were no changes to the policy.
   2. References:
      1. https://technet.microsoft.com/en-us/library/cc978250.aspx
      2. http://www.thewindowsclub.com/disable-background-processing-registry-policy

1. Make a change to a policy in the security section, that’s the piece the CSE is responsible for and triggers a re-run which then creates the Winlogon.log

In any case, please make sure you undo the changes you’ve done for troubleshooting!

Winlogon.log is a debugging file which you should enable if needed to find and fix your issues but then disable it later again. Same for the NoListChanges, please make sure that you revert this change back!

Hope you enjoyed the post and it saves you some time in finding the Winlogon.log file now.

Regards,

Michael

Hello, Paul Bergson back again with a discussion on the newly built-in memory protection features provided in Windows 10 and Windows Server 2016. I refer to Win10 throughout the document, but this is just for brevity sake.

For a complete discussion on how to “Migrate threats by using Windows 10 security features” please see the below link.
https://technet.microsoft.com/en-us/itpro/windows/keep-secure/overview-of-threat-mitigations-in-windows-10

With the Enhanced Mitigation Experience Toolkit (EMET) being sunset, folks are wondering what the next steps are to protect from malware attacking memory. EMET’s current support is set to expire on August 1, 2018. EMET version 5.52 has features that still don’t reside in Windows 10, so it is recommended to continue to use EMET within your infrastructure. *21

EMET provided the ability to protect memory corruption attacks against individual applications. When software was created, it may not have been built to work with specific memory protection features, so having a defensive mechanism (software) to force these protections on all applications, could render the some of the applications unusable. What EMET did was allow protective controls over individual applications (via shims) therefore allowing an administrator to pick and choose which protection features to apply against individual applications. As EMET begins to age, we have begun to build into the o/s, the features that EMET has provided in the past. “Moving Beyond EMET” *22

With EMET there was a front-end GUI that could be used to control individual desktops but if an enterprise wanted to manage large volumes of desktops, a singular GUI approach wouldn’t scale well. Therefore, as we build the new memory protection features into the operating system we look to provide manageability with application specified protection and GPO’s.

Some of the memory protection features for Windows 10 don’t require any configuration from the device administrators, since the application can be configured to leverage memory protection features with the simple selection within the source code. Software developers have had the option to enable Control Flow Guard since Microsoft released Visual Studio 2015.

“Control Flow Guard (CFG) is a highly-optimized platform security feature that was created to combat memory corruption vulnerabilities. By placing tight restrictions on where an application can execute code from, it makes it much harder for exploits to execute arbitrary code through vulnerabilities such as buffer overflows. CFG extends previous exploit mitigation technologies such as /GS, DEP, and ASLR.” *23

There is no need (in most instances) for your developers to modify the source code, all that is required is to enable the CFG option and recompile the code.

So how does CFG work?

In simplistic terms, at compile time there is a bit map table built of all the legitimate target locations the code can jump too. During the execution of the application, whenever there is a call to jump to a new target location, CFG verifies that the new location was in the bit map table of valid jump locations. If the requested jump location is not listed in the “Valid Jump Locations”, Windows terminates the process thereby preventing the malware from executing.

*24

If you want to know which applications have enabled CFG on your system (Windows 10), you can start up SysInternals ProcessExplorer (v16.20). By default, the column “Control Flow Guard” isn’t displayed so it will have to be added. View / Select Columns / Process Image (tab) – Select “Control Flow Guard”.

Under the “Control Flow Guard” column, there are three values that are possible:

1. Blank    – Not enabled
2. CFG    – Enabled
3. n/a     – Not applicable

If the application, you want to use doesn’t have CFG enabled there are “Post Compile” fixes available within the Windows 10 operating system (Win10 1607). Specifically, there are two GPO settings within the “Mitigation Options” that can be configured.

The GPO policy settings can be found at:
computer configuration\administrative templates\system\Mitigation Options

“Untrusted Font Blocking” is the first setting, which provides a global setting to prevent programs from loading untrusted fonts. Untrusted fonts are any font installed outside of the %windir%\Fonts directory. This feature can be configured to be in 3 modes: On, Off, and Audit. By default, it is Off and no fonts are blocked. If you aren’t quite ready to deploy this feature into your organization, you can run it in Audit mode to see if blocking untrusted fonts causes any usability or compatibility issues. If you are also using EMET, it is recommended to use the Windows 10 “Untrusted Font Blocking” setting over EMET’s.

The second GPO configurable setting has 6 manageable memory protection features available to apply against any process on the Win10 operating system. These 6 (A-F) settings are a part of a 32 bit, bit mask shown in the figure below. These 6 mitigations were considered the ones to be the most impactful on the system and as you can see there is plenty of growth opportunities for future protection options.

The six settings in this topic are related to three types of process mitigations. In Windows 10, all three types are on by default for 64-bit applications, but by using the Group Policy settings described in this topic, you can configure these additional protection options. *25

• Data Execution Prevention (DEP)
• Structured Exception Handling Overwrite Protection (SEHOP)
• Address Space Layout Randomization (ASLR)

The “Process Mitigation Options” security feature provides a means to override individual process MitigationOptions settings. This can be used to enforce a number of security policies specific to applications. The application name is specified as the Value name, including extension. The Value is specified as a bit field with a series of flags in particular positions. Bits can be set to either 0 (setting is forced off), 1 (setting is forced on), or ? (setting retains its existing value prior to GPO evaluation). The recognized bit locations are:

PROCESS_CREATION_MITIGATION_POLICY_DEP_ENABLE (0x00000001)
Enables data execution prevention (DEP) for the child process

PROCESS_CREATION_MITIGATION_POLICY_DEP_ATL_THUNK_ENABLE (0x00000002)
Enables DEP-ATL thunk emulation for the child process. DEP-ATL thunk emulation causes the system to intercept NX faults that originate from the Active Template Library (ATL) thunk layer.

PROCESS_CREATION_MITIGATION_POLICY_SEHOP_ENABLE (0x00000004)
Enables structured exception handler overwrite protection (SEHOP) for the child process. SEHOP blocks exploits that use the structured exception handler (SEH) overwrite technique.

PROCESS_CREATION_MITIGATION_POLICY_FORCE_RELOCATE_IMAGES_ALWAYS_ON (0x00000100)
The force Address Space Layout Randomization (ASLR) policy forcibly rebases images that are not dynamic base compatible by acting as though an image base collision happened at load time. If relocations are required, images that do not have a base relocation section will not be loaded.

PROCESS_CREATION_MITIGATION_POLICY_BOTTOM_UP_ASLR_ALWAYS_ON (0x00010000)

PROCESS_CREATION_MITIGATION_POLICY_BOTTOM_UP_ASLR_ALWAYS_OFF (0x00020000)

The bottom-up randomization policy, which includes stack randomization options, causes a random location to be used as the lowest user address.

The CFG policy is per application, similar to how EMET is configured, in that to apply against an application (remember by default it is applied against all 64 bit applications) you must define the application within the policy.

For example:
Enable    – PROCESS_CREATION_MITIGATION_POLICY_DEP_ENABLE
Enable    – PROCESS_CREATION_MITIGATION_POLICY_FORCE_RELOCATE_IMAGES_ALWAYS_ON
Disable    – PROCESS_CREATION_MITIGATION_POLICY_BOTTOM_UP_ASLR_ALWAYS_OFF
Leave all other options at their default values, specify a value of:

???????????????0???????1???????1

Setting flags not specified here to any value other than “?” results in undefined behavior.

To help understand how EMET mitigations are being built into Windows 10, there is a matrix (below) to show the progress we are making. As the operating system moves forward, we will continue to improve the protection to help our customers with “legacy” apps that cannot be recompiled for CFG.

Certificate Pinning wasn’t a memory protection feature, but EMET provided this to help protect against Man-in-the-Middle attacks.

“Enterprise certificate pinning is a Windows feature for remembering, or “pinning,” a root issuing certificate authority or end entity certificate to a given domain name. Enterprise certificate pinning helps reduce man-in-the-middle attacks by enabling you to protect your internal domain names from chaining to unwanted certificates or to fraudulently issued certificates.”

“…restrictions are encapsulated in a Pin Rules Certificate Trust List (CTL) that is configured and deployed to Windows 10 computers. Any site certificate triggering a name mismatch causes Windows to write an event to the CAPI2 event log and prevents the user from navigating to the web site using Microsoft Edge or Internet Explorer.” *26

Windows 10 GA initially just provided logging capabilities, but with “Creators Update” administrators can now block sites with certificate errors.

For complete details on how to deploy enterprise certificate pinning, please see link reference 26 below.

I would strongly recommend you read the page “Migrate threats by using Windows 10 security” referenced above, as well as the resource links found throughout this document.

Hopefully you found this Blog article useful and enjoy the linked reading.

1. Fonts https://technet.microsoft.com/en-us/itpro/windows/keep-secure/block-untrusted-fonts-in-enterprise
2. Force Application Mitigation-Fonts row should show as no/red in the Windows 10 + EMET column, as the ability to configure the Untrusted Fonts mitigation for specific applications has been disabled in EMET
3. https://support.microsoft.com/en-us/kb/2639308
4. PROCESS_CREATION_MITIGATION_POLICY_IMAGE_LOAD_NO_REMOTE_ALWAYS_ON
5. PROCESS_CREATION_MITIGATION_POLICY_PROHIBIT_DYNAMIC_CODE_ALWAYS_ON
6. PROC_THREAD_ATTRIBUTE_CHILD_PROCESS_POLICY
7. ProcessSignaturePolicy
8. ProcessSystemCallDisablePolicy
9. From 1510
10. https://www.blackhat.com/docs/us-16/materials/us-16-Weston-Windows-10-Mitigation-Improvements.pdf
11. See UpdateProcThreadAttribute documentation for PROCESS_CREATION_MITIGATION_POLICY_HIGH_ENTROPY_ASLR_ALWAYS_ON
12. See UpdateProcThreadAttribute documentation for PROCESS_CREATION_MITIGATION_POLICY_STRICT_HANDLE_CHECKS_ALWAYS_ON
13. See UpdateProcThreadAttribute documentation for PROCESS_CREATION_MITIGATION_POLICY_EXTENSION_POINT_DISABLE_ALWAYS_ON
14. See UpdateProcThreadAttribute documentation for PROCESS_CREATION_MITIGATION_POLICY_HEAP_TERMINATE_ALWAYS_ON
15. https://blogs.technet.microsoft.com/srd/2013/10/29/software-defense-mitigating-heap-corruption-vulnerabilities/
16. https://blogs.technet.microsoft.com/srd/2009/11/20/sehop-per-process-opt-in-support-in-windows-7/
17. https://blogs.technet.microsoft.com/srd/2013/12/11/software-defense-mitigating-common-exploitation-techniques/
18. https://media.blackhat.com/bh-us-12/Briefings/M_Miller/BH_US_12_Miller_Exploit_Mitigation_Slides.pdf
19. The NULL page mitigation provided by the OS (enabled by default) obsoletes the EMET NULL page mitigation, see [21]
20. CFG must be enabled by the application and cannot be forced-on
21. https://support.microsoft.com/en-us/help/4002093/support-extended-for-microsoft-enhanced-mitigation-experience-toolkit
22. https://blogs.technet.microsoft.com/srd/2016/11/03/beyond-emet/
23. https://msdn.microsoft.com/en-us/library/windows/desktop/mt637065(v=vs.85).aspx
24. https://channel9.msdn.com/Events/Ignite/New-Zealand-2016/M401
    
25. https://technet.microsoft.com/en-us/itpro/windows/keep-secure/override-mitigation-options-for-app-related-security-policies
26. https://technet.microsoft.com/en-us/itpro/windows/keep-secure/enterprise-certificate-pinning

Special thanks to Jeffrey Sutherland, for his invaluable content contribution!

Hello there, Chad Munkelt here! Are you still using Roaming User Profiles in your environment? Are you running Windows 10? Are you running non-persistent VDI’s? Do your Start Menu Tiles keep disappearing or become unstable? Then, you have come to the right blog. I’m going to explain a new hotfix and registry key setting which was released in the March 14, 2017 CU that fixes just that.

Roaming profiles have been around for a long time, and many organizations have decided to stick with them even though more modern technologies such as UE-V with Folder Redirection or Enterprise State Roaming have been created. This decision could be technical, political, or simply, they just work. I’m not going to debate which is better or worse, nor am I going to tell you how to roam the start menu so a user’s customizations follow them from PC to PC. I am going to tell you how to make the Start Menu (mandatory or not) and Roaming User Profiles play nice together.

Recently, while deploying Windows 10 1607 to my customer I noticed that most, if not all start menu tiles, would simply disappear. In addition, many of the apps in the Apps Menu would not execute. This was only happening in our Virtual Desktop Infrastructure (VDI) environment. It appeared that when using thick clients, everything was fine. The significant difference between our VDI environment and thick clients was the fact that our VDI’s are non-persistent. Meaning, after every logoff all changes to the VDI are reverted to an initial state, based on a master virtual machine.

When users logged onto the VDI for the first time, and a new v6 profile was created, the start menu and apps folder was fine. The user could work as normal. As soon as they logged off, their local profile was deleted and the VDI reset to its baseline. When users logged on a second time, the start menu was missing most of its tiles. This happened regardless of mandatory profiles or not.

Enter March 14, 2017—KB4013429 (OS Build 14393.953) for Windows 10 1607 and March 14, 2017—KB4013198 (OS Build 10586.839) for Windows 10 1511. The Knowledge Base articles have a very small one liner that states

•Addressed issue that causes Start menu and other items to disappear or malfunction when using roaming user profiles

This is great news! However, if you install it, it does not fix the issue. Interesting. If you have been around for a while, and have used roaming profiles for quite some time, you already know how to set up roaming profiles. There really is no reason to recheck the documentation to see if anything has changed, right? Well, sadly, that is not correct, and I am guilty of doing just that myself. In order for this hotfix to work we must make a small registry change that needs to be done before it can take effect.

Per the Deploying Roaming User Profiles there is a new step to using Roaming User Profiles in Windows 10, which is Step 7. You need to enable the SpecialRoamingOverrideAllowed key for the Start menu to display and work correctly. I didn’t pick the name for the registry key, I just work here. Below are the steps mentioned in the hyperlink. It does state mandatory start menu layouts; however, if you are not using mandatory start menus, you can still test it out in a DEV environment and make sure it works for you. This registry key of course can be deployed via GPO, set in your base image, or baked into your master VDI. I personally like the GPO option because it allows me to centrally control it, but, it is up to you how you want to deploy it.

Step 7: Optionally specify a mandatory Start layout for Windows 10 PCs

You can use Group Policy to apply a specific Start menu layout so that users see the same Start layout on all PCs.

To specify a mandatory Start layout, do the following:

1. Update your Windows 10 PCs to Windows 10 version 1607 (also known as the Anniversary Update) or newer, and install the March 14th, 2017 cumulative update (KB4013429) or newer.
   
2. Create a full or partial Start menu layout XML file. To do so, see Customize and export Start layout.
   If you specify a full Start layout, a user can’t customize any part of the Start menu. If you specify a partial Start layout, users can customize everything but the locked groups of tiles you specify. However, with a partial Start layout, user customizations to the Start menu won’t roam to other PCs.
   
3. Use Group Policy to apply the customized Start layout to the GPO you created for Roaming User Profiles. To do so, see Use Group Policy to apply a customized Start layout in a domain.
   
4. Use Group Policy to set the following registry value on your Windows 10 PCs. To do so, see Configure a Registry Item.
   

I would like to point out, this DOES NOT allow the start menu to roam from PC to PC, so changes will not move with the user. I hope this helps, and sheds some light on the importance of this setting if you fall into that unique situation of VDI’s, non-persistence, and roaming profiles. Good luck! -Chad Munkelt

Hello world; Brandon Wilson here, with a special thanks to Tony Gaston in our support wing, here to talk to you briefly about changes in DNAME resolution for Windows Server 2012 R2 that were introduced in KB3133954. More specifically, if you look at the “Known issue” section of KB3133954, you will find that it states:

“After you install this update, the DNAME resolution by Microsoft DNS Servers will be changed.

Previously, you could query for the domain (type=ANY or type=A) example.com, and get back the host (A) record for the DNAME. After you install this update, that query fails.

This change was made for compliancy with RFC 6672.”

So, let’s dive into this a little bit more shall we?? Per the RFC, the DNAME applies only to objects within the domain, and not to the domain itself. The bottom of page 4, along with pages 5 and 6 in the RFC talk about this behavior more in detail, so I’ll try not to get too wordy on that. First, let’s look at the high-level RFC defined behavior, where if you query the DNAME directly, you get the DNAME response back (this is from RFC 6672):

Here are some more specific examples to chew on; hopefully they help you see the new behavior:

Now that we have all of that covered, we may as well talk a bit about KB3133954 itself… The actual KB title is “DNSSEC validation fails when incorrect response to DNSKEY query is sent on Windows Server 2012 R2-based DNS server”. The high-level overview is that this is to correct an issue where if a DNSKEY query is targeted for a name that has a DNAME, then it will respond back with the DNSKEY rather than the “correct”/expected target name. So, in correcting 1 issue, you are actually correcting both that issue, as well as refining your DNS servers to be RFC compliant. In the context of the behavior change however, DNSSEC is a separate topic altogether, and the KB is only an introduction point to the changes made for DNAME resolution.

And in a nutshell, that’s pretty much it. I just wanted to let everyone know about the changes and provide a bit of an example to maybe, just maybe, eliminate some head scratching! Hey, we can all dream right…?

References:

DNSSEC validation fails when incorrect response to DNSKEY query is sent on Windows Server 2012 R2-based DNS server

https://support.microsoft.com/en-us/help/3133954/dnssec-validation-fails-when-incorrect-response-to-dnskey-query-is-sent-on-windows-server-2012-r2-based-dns-server

RFC 6672: DNAME Redirection in the DNS

https://tools.ietf.org/html/rfc6672

Thanks for reading everyone!

Brandon Wilson, Sr. Premier Field Engineer, Platforms and Active Directory

Hello, Michael C. Bazarewsky here again, with another short clarification post.

In February, we published Features that are removed or deprecated in Windows 10 Creators Update (KB 4014193). Someone I follow on Twitter noticed this part:

The X’s here indicate those features are deprecated. This occasionally comes up still on Twitter, with at least one person seeing this as a real issue…

But I was curious – what was the driving factor behind this deprecation? After all, you’d expect that if features improve performance reliably, and are in heavy use, we wouldn’t deprecate them, right? Well, it turns out, by phrasing the question that way, I’ve walked you down the garden path a bit.

I reached out internally, and found out some interesting information that I’m not sure was particularly widely known, although you can see hints of it.

Before explaining why they are deprecated, though, I should explain what each of these features did, in theory, to explain why they were ever listed as features at all. After all, you can’t really understand the implications of a change without understanding the original state, right?

First, let’s talk about TCP Chimney, which is part of a larger concept known as TCP Offload Engine (TOE.) TCP Chimney moves part of basic TCP processing to a dedicated circuit on a network card. There are different levels of TOE implementation; TCP Chimney is a subset where the basic setup of a TCP connection is still handled by the host operating system stack, but once a connection is active, the encapsulation and de-encapsulation of data from the network stack into TCP packets over the connection is handled by the offload engine. The benefit is that it removes workload from the operating system and the host system processor cores. However, this benefit comes with some noticeable costs, as well:

• If there is a flaw in the TCP implementation in the network card, for example a security issue, you are potentially looking at a firmware update on the network card, or worse, you may be stuck with it, depending on the card implementation and the vendor’s support policy for the network card.
• Under heavy network loads, performance may actually drop, because you’re limited to the resources on the network card, which may be a bottleneck relative to a fast operating system stack with fast, available processor cores.
• The cost for all TCP connection offloading is fixed; there’s no way for the operating system to optimize specific use cases. The feature assumes that the fixed cost will be offset by the CPU savings, thus there will be an overall improvement in performance. However, improvements in processor performance combined with what real-life TCP workloads look like suggest that, in 2017, ~99% of real-life connections will send enough data for the performance arithmetic to work out.
• The NIC code wasn’t necessarily written with TCP in mind; thus, not all TCP features are implemented. For example, the TCP performance enhancement known as Selective Acknowledgement (RFC 2018, from 1996 [!!]), can’t be used with TCP Chimney.

Windows first introduced TCP Chimney support as part of the Windows Server 2003 Scalable Networking Pack. As explained in KB 912222, even when first released, TCP Chimney had conflicts with other possible performance enhancements – so even at release, a customer saw the issue of not being able to leverage intelligence in the operating system network stack. Over time, as users called in with support cases, network card drivers were released to the Windows Update Catalog, and operating systems and servers moved forward, we found that several things were true:

1. Very few users actively used TCP Chimney support.
2. Very few network cards implemented the functionality.
3. Over time, less and less customers cared, and less and less NICs offered the ability.
4. In the Windows 7 / Windows Server 2008 R2 timeframe, we found that the number of customer support cases around this dropped to zero.
5. In Windows 8 / Windows Server 2012, we changed the operating system to disable this functionality by default. There was not a customer pushback on this.
6. The industry in general has decided this is not a necessary feature. For example, the Linux kernel has never implemented this capability, although some specific network card drivers did implement it, generally poorly. You do not need to take my word for this – the Wikipedia article on TCP Offload covers it sufficiently.

Thus, the end result of all of this is that the TCP Chimney deprecation in Windows 10 Creators Update is really not a new thing, because disabling it by default was a signal of the future direction. Furthermore, there are no current mainstream network cards that implement this feature, and customers are not reporting a need for this functionality. So, although deprecation of a feature is something customers generally need to be aware of and plan for, in this case, that’s not a real life concern.

But what about the second deprecated feature, IPsec Task Offload? Well, this is another case of the concept of transferring computing responsibility from the host processor to the network card. However, this is not basic processing of TCP packets in this case. Instead, IPsec Task Offload, as the name implies, moves the encryption and decryption tasks for network data protected with IPsec to the network card. As you can imagine, this also requires a smarter network card, with more complicated firmware. Thus, all of the issues around updates and patches that were present for TCP Chimney are also present here. Further, because the whole point of IPsec is to secure network communications, security issues are arguably more critical to correct in this scenario.

Now, all of that may be okay if there was a sufficient benefit to customers. However, again based on customer support cases and driver support, we know that several things are true:

1. Processors and systems have gotten fast enough, and have added enough supporting processor instructions, that in most cases IPsec can be done quickly and efficiently on the host (and for that matter, more cost effectively), and improves faster than network card offloading technology. (This does, admittedly, leave the possibility of a workload that is so stressful on the host CPU that offloading could improve performance, although that’s an uncommon edge case. That said, it’s important to remember that “deprecated” does not mean “removed.”)
2. Management of IPsec secrets can be complicated, and needing to interact with the network card to manage those adds another layer of complexity.
3. Conceptually, IPsec is a critical security feature in environments where it is used. All vulnerabilities that may exist are essentially critical vulnerabilities by definition; thus, the ability to quickly deploy changes is critical. As a major operating system vendor offering IPsec functionality, Microsoft has the dedicated security staff and deployment capability (with Windows Update) to make this happen.
4. Only one certified network card – an older Intel card – ever implemented this feature fully. No modern shipping mainstream network cards implement this functionality.
5. In the Windows 7 / Windows Server 2008 R2 timeframe, we found that the number of customer support cases around this dropped to zero.
6. Over time, the industry appears to be moving to TLS over IPsec for many use cases, such as VPN solutions, thus lowering the importance of IPsec workloads on Windows machines.

You may notice one of those points – the point around the number of support cases – is a duplicate from the list for TCP Chimney. This is not a coincidence. In both cases, it’s clear from customer interaction that real-world impact of deprecation of these features will be near zero. And, as mentioned above, because deprecation is not the same as removal – the whole point of deprecation is to act as a customer warning point and allow reaction from the user community and ensure that we aren’t missing something or breaking existing environments – there’s always the chance for us to be proven wrong on this.

I hope you find this information helpful in understanding some of the thinking behind these features being deprecated (and, by extension, some of what we use in general for these decisions.)

Thanks!

p.s. What if you feel you are indeed impacted by these changes? In that case, that’s what support channels are for. Open a support case, or, if you have Premier support, request a design change (DCR) through your account team. That’s why we have those channels

p.p.s. special thanks to Daniel Havey, Mihai Peicu, Praveen Balasubramanian, Don Stanwyck, and Doug Stamper for technical review assistance and background information!

Hi everyone. Graeme Bray here with an article around using Computer Name Aliases instead of DNS CName records.  In the past, we used to set the registry key DisableStrictNameChecking to be able to add a DNS alias to connect via a name (such as fileserver.contoso.com).  Starting with Windows Server 2008, we added functionality to be able to create a computer alias.

What benefits does using computer aliases provide?

• Automatic SPN management for Kerberos authentication.
• No DNS access required
• Automatic DNS entry updates for DNS A Records.
• Eliminate the need and risk of editing the registry for “DisableStrictNameChecking” and “OptionalNames” keys

What benefits does using a DNS CName provide?

• Aliases pointing to a computer name, not an IP address

To create a computer name alias, it’s a very simple process. You need to run as an elevated Powershell (or command prompt) window. Enter the command as below, and you’re done.

Command:

Netdom computername <COMPUTER> /add:<ALIAS>

Example:

Netdom computername IIS01 /add:webapp.surface.graemebray.com

This adds the DNS entry appropriately. To confirm, do one of the two following steps:

1a. Open DNS and look for your entry (sort by name or IP address)

1b. Query for the machine and entries you submitted via PowerShell.

This will allow you to securely access SMB shares.  It’ll register the DNS A record, register additional SPNs, and add OptionalNames registry key.  It’ll save you from modifying SPNs manually and no CNAME mess.

Verify ComputerName Aliases

The most important part to confirm is after we have finished all of this work. We know the DNS entry exists, but how can we confirm the computer object contains all of the appropriate aliases? If we stick with my IIS01 machine, we can run: netdom computername iis01 /enum

This will output a list of all computer names associated with this object.

Verify Service Principal Names

The most important reason to do all of this work is to have all of the Kerberos magic done for you. This can also be verified once the above sets of steps are completed.

If you run setspn -l <computer> you can see the list of all SPN records created.

Remove Computer Alias

The ability to remove the alias is just as easy. Swap “add” for “remove”, and you’re good to go.

Netdom computername <COMPUTER> /remove:<ALIAS>

Troubleshooting:

Below are some troubleshooting tips if you run into errors when trying to create a computername alias.

Problem #1:

“The specified domain either does not exist or could not be contacted.”

Solution:

Make sure you have connection to the domain controller. In my example, I didn’t have an IP address.

Problem #2:

“Access is denied”

Solution:

The user ID must have Write permissions to msDS-AdditionalDnsHostName on the object within Active Directory. You can see the modification attempt via the packet capture data below.

Problem #3:

“The system cannot open the device or file specified.”

Solution:

This computer name alias already belongs to another machine. Be careful with this issue, at time of this writing, on Server 2012 R2, the computer name alias will show up on the second machine you run it on.

Additional Reading:

Here are the pertinent Technet links/articles, as always:

Netdom Computername: https://technet.microsoft.com/library/cc835082(v=ws.11).aspx

SetSPN: https://technet.microsoft.com/library/cc731241(v=ws.11).aspx

Brad Watts here to talk with you today about extending OMS with SCCM information. Microsoft Operations Management Suite (OMS) is a very powerful cloud based tool. There are bunch of out of the box solutions like Alert Management, Active Directory Assessment, SQL Assessment, Update Compliance, etc.. We’re not going into details of what OMS is or how to use the solutions that are available to you. If you aren’t familiar with the what OMS is and the benefits of the tool I strongly suggest you spend just a little bit of time browsing the OMS website here: https://www.microsoft.com/en-us/cloud-platform/operations-management-suite

All of the out the box solutions available in OMS are great but what if we have information that isn’t ingested through a solution but we’d like to take advantage of the extremely powerful Log Analytics Search API. Well that’s where the OMS Ingestion API comes into play.

OMS Ingestion API

The OMS Ingestion API is a PowerShell module that is available that allows us to send any information that we can gather through PowerShell to our OMS Workspace. The gist of how it works is the following

1. Gather the information you want to send to the OMS Workspace
2. Put the gathered information into a JSON payload
3. Use the Send-OMSAPIIngestionFile command from the OMS Ingestion API to send the information to your OMS Workspace.

Below we will walk through these steps with an example of sending some of your inventory information from SCCM. To find out more and get the OMS Ingestion API go here:

https://www.powershellgallery.com/packages/OMSIngestionAPI/1.5

SCCM Installed Software

Our first example will query the SCCM database to get all of the installed software for our systems. We’ll walk through the PowerShell script so you understand it. I will also provide a link to the script file at the bottom of the blog.

Our first step in the process is to gather the information we want to send to OMS. In this example we are getting the information from the SCCM Database. In this case I typically start in SQL Management Studio to get a valid query. Below is the query we’ll use to get our Installed Software:

SELECT vrs.Netbios_Name0 AS [Device Name],vrs.Name0 + '.' + vrs.Full_Domain_Name0 as FQDN,vProg.DisplayName0 as [Program Name],vProg.InstallDate0 as [Install Date],vProg.Version0 as [Version]
from dbo.v_r_system as vrs
Left OUTER JOIN dbo.v_Add_Remove_Programs as vProg on vProg.ResourceID=vrs.ResourceID
WHERE vProg.DisplayName0 != 'NULL' and vrs.Active0=1
order by vrs.Netbios_Name0,vProg.Displayname0

I’m not going to bore you with the details of the SQL Query but this query run against your SCCM DB will bring back the Computer Name, FQDN, Program Name, Install Data, and Version for each computer where the SCCM Hardware Inventory has been run.

Now that we have our query we need to move this over to PowerShell and make a connection to our database. To simplify this process I’m utilizing the SQLManagement module that is available here:

https://gallery.technet.microsoft.com/scriptcenter/SQL-PowerShell-Module-0d1e38ec

Once you’ve imported this module into your script you can utilize the following PowerShell code:

$instancename="<your db server/instance name>"
$dbname="<SCCM DB Name>"
$query="<insert query from above>"
$connectionstring = "Data Source=$instancename;Integrated Security=SSPI;Initial Catalog=$dbname"
$dataset = Invoke-SqlQuery -ConnectionString $connectionstring -Query $query

In the above code block you will need to fill in the $instancename variable. An example would be “LAB-SQL\SCCM” if you have a named instance. You also need to fill in the $dbname variable with the name of your SCCM database.

After you run this set of code you will have a variable named $dataset that contains all of your information. We want to take this information and send it to OMS but in order to do this we need to convert it to a JSON payload. Luckily PowerShell makes this a relatively painless process. It just takes a couple of steps.

First step, take our $dataset and create an array that contains PSObjects. To represent our Installed Software Query our PSObject will have the following Properties:

• FQDN
• NetBiosName
• ProgramName
• Version
• InstallDate

You’ll notice we just created a property for each of the values returned from the query. Below is what this looks like in PowerShell.

$DataComponentArray=@()
foreach($item in $dataset) {
$sx = [pscustomobject]@{
"FQDN"=$item.FQDN;
"NetBiosName"=$item.'Device Name';
"ProgramName"=$item.'Program Name';
"Version"=$item.Version;
"InstallDate"=$item.'Install Date'
}
$DataComponentArray+=$sx
}

Basically, we are looping through our $dataset, creating a new PSObject for each row and assigning it to $sx, and then adding $sx to our array which is $DataComponentArray.

Second step is to convert your array to a JSON payload. Once you have your array of PSObjects this is a single line of code.

=$json = $DataComponentArray | ConvertTo-Json

Now that we have the JSON payload we just need to send the information to our OMS Workspace. In order to do that you’ll need to import the OMS Ingestion module using import-module OMSIngestionAPI (make sure you’ve already installed it on the box your running the script from) and gather the following information from your OMS Workspace:

• Customer ID: OMS Portal -> Settings -> Connected Sources -> Windows Servers -> Workspace ID
• Shared ID: OMS Portal -> Settings -> Connected Sources -> Windows Servers -> Primary Key

Here is what our PowerShell code looks like:

$customID = "<Workspace ID>"
$sharedID = "<Shared ID>"
$time = Get-Date
Send-OMSAPIIngestionFile -customerId $customID -sharedKey $sharedID -body $json -logType "SCCMSoftware" -TimeStampField $time -Verbose

We know have a PowerShell script that when run will send our Installed Software information from SCCM up to our OMS Workspace. The only thing left is to schedule this to run on a regular basis. I’ll leave that up to you but some of your options would be:

• Windows Scheduled Task
• System Center Orchestrator
• Azure Automation with Hybrid Worker

That’s pretty much it! We named our field “SCCMSoftware” so now that we’ve run the script, lets explore it in OMS.

Exploring the Data in OMS

In the OMS Portal we’ll open the log search page and do a simple search on “*” just to make sure our data has arrived:

Now that we see there is “SCCMSoftware_CL” data available we’ll just select it to explore the info more.

Now you see each one of the records along with the properties we added to our array in PowerShell. We can continue to explore this data just like any other data sent to OMS. I’ll finish off this blog by showing a couple of searches that may be useful for you.

Our first search will give us the count of each program by version. To do this we can simply run this query: Type=SCCMSoftware_CL | measure count() by ProgramName_s,Version_s

What if we wanted to look at a specific program and get the computers it’s installed on, the version installed, and the install date. In this case we could simply run the following query: Type=SCCMSoftware_CL ProgramName_s=”Microsoft Silverlight” | select NetBiosName_s,Version_s,InstallDate_s | display Table

This is just a couple examples of how you can use the search in OMS to quickly gather the information you need.

Summary

My goal in this blog is to show the power of the PowerShell OMS Ingestion API. The power of the Log Analytics search is something we want to take advantage of. When you combine PowerShell with the OMS Ingestion API this allows us to send whatever data that we want to our OMS Workspace. Today we looked at pulling the SCCM Installed Software Inventory and sending that to OMS. But the true power of this solution is that whatever we can pull with PowerShell we can ingest into our OMS Workspace.

Here is the link to an example PowerShell script to ingest SCCM information:

https://1drv.ms/f/s!Am5WunbinyvqtclH2TC-1DnKbWy0tA

***This post was written by Ralph Kyttle, PFE, and back linked to the original post. The original post can be found at: https://blogs.technet.microsoft.com/ralphkyttle/2017/04/05/dscea-1-2-0-0-has-been-released-introducing-exciting-new-updates-to-start-dsceascan/

For more information on DSCEA, please review the original post on the topic located at https://blogs.technet.microsoft.com/ralphkyttle/2017/03/21/introducing-dscea/ or https://blogs.technet.microsoft.com/askpfeplat/2017/04/04/introducing-dscea/

DSCEA 1.2.0.0 has been released!!!

Just as a recap on DSCEA:

DSC Environment Analyzer (DSCEA), is an open source PowerShell module that uses the declarative nature of Desired State Configuration to scan systems in an environment against a defined reference MOF file and generate compliance reports as to whether systems match the desired configuration.

DSCEA includes a customizable reporting engine that can provide reports on overall compliance and details on any DSC resource found to be non-compliant.  DSCEA utilizes the DSC processing engine and DSC resources to audit and report on the existing configuration of machines in an environment.

By using PowerShell Desired State Configuration at its core, DSCEA obtains some unique advantages. Most notably, by defining the desired configuration state using DSC, an admin can benefit from using the same work to both scan for compliance and then correct items that were found to be non-compliant. Building an audit file in DSC can help ease remediations, and in some cases it can be as simple as applying the same MOF file that was used to scan an environment onto systems to correct drift and bring things into the desired state.

DSCEA is hosted at https://github.com/Microsoft/DSCEA and can be downloaded from the PowerShell Gallery.

Details on this release are listed below:

• Introduced exciting new updates to Start-DSCEAscan
  
  • Automatic copying of any custom resources needed for a scan from the management system to the remote endpoints being scanned
    
    • Thank you to Anthony Watherston for adding this capability to DSCEA!
      
  • Added a new Path parameter, which allows Start-DSCEAscan to take in a folder path containing machine specific MOF files to allow for a scan of those systems against unique per system settings
    
• Added additional config examples
  
  • Config that uses non built-in DSC resources
    
  • Config that showcases using the DSC script resource
    
    • Thank you to Patrick Mercier for your contributions and feedback on this!
      
• Bug fixes
  
  • Fixed issue where errors were thrown when running Import-Module DSCEA
    
    • Thank you to Melissa Januszko for pointing this out!
      
  • Fixed quote character issue when running Get-Help Start-DSCEAscan
    
• Documentation updates
  
  • Clarified instructions on Report Generation with Power BI page
    
    • Thank you to Zachary Alexander for updating this page!
      
  • Clarified instructions on PowerShell Gallery – Offline Install page
    
  • Added page – Convert DSCEA scan result to CSV
    
  • Added page – DSCEA Functions Reference
    

Real world examples of how DSCEA can be used include

• Verifying a single setting, for example if a registry key is set appropriately across your entire environment
  
• Auditing your systems to ensure that they meet the base level system configuration settings that are required to be a part of your environment
  
• Scanning the systems in your environment against all of the items that make up your organization’s security baseline
  
• Verifying that settings configured via Group Policy are being applied correctly to the systems in your environment
  
• Verifying settings configured on Windows Server 2016 Nano servers (which do not support Group Policy)
  

Links

https://www.powershellgallery.com/packages/DSCEA
https://github.com/Microsoft/DSCEA
https://microsoft.github.io/DSCEA

Hello, my name is Jason Krause and this is my first time writing a blog post for AskPFEPlat. I am a Platforms PFE here at Microsoft and work primarily in Active Directory and Group Policy. Recently a customer approached me with a question I thought I knew the answer to, “Can the administrator account be locked out”? In their environment, a security scanning tool was attempting to log into the RID 500 Administrator account with invalid credentials. This activity was generating lock out events that were being collected by their security information and event management (SIEM).

In Active Directory, an account lockout occurs when the amount of failed logon attempts exceeds the allowed limit set in Group Policy. Each time a bad password is presented to the domain controller, the “badPwdCount” attribute is incremented on that account. Account lockout policy is defined once per domain, traditionally in the Default Domain Policy.

Note: The current recommended security baseline for Account Lockout Threshold should be set to a minimum of 10 invalid login attempts. These settings may not be right for your organization. Please refer to Aaron Margosis’ post on configuring account lockout. NIST currently recommends limiting invalid login attempts to 100.

Account lockout threshold: How many bad password attempts are allowed before the account is locked out on the domain controller? This setting is also referred to as the “LockoutThreshold”

Account lockout duration: How long should the account remain locked out after exceeding the threshold?

Reset account lockout counter after: After the first bad password is attempted, how long should the domain controller record subsequent attempts? This setting is also referred to as the “ObservationWindow”

When a normal domain user attempts to log in with an account that has been locked out, Kerberos returns a KDC_ERR_CLIENT_REVOKED. This is true even if the correct password is typed.

KRB_AS_ERROR, KDC_ERR_CLIENT_REVOKED: Clients credentials have been revoked, Cname: testuser, Realm: contoso, Sname: krbtgt/contoso

When the Administrator (RID 500) account is locked and another bad password is attempted, Kerberos returns a KDC_ERR_PREAUTH_FAILED.

KRB_AS_ERROR, KDC_ERR_PREAUTH_FAILED: Pre-authentication information was invalid, Cname: administrator, Realm: contoso, Sname: krbtgt/contoso

The two differences for the Administrator account are

1. The authentication package ignores the Lockout attribute and returns a failed login
2. The Lockout attribute is reset upon successful login.

This behavior can be changed by modifying the domain PasswordProperties attribute, but I would caution against this change.

DOMAIN_PASSWORD_INFORMATION structure

To answer the original question, you can lock out the administrator account, but by default it does not stay locked out.

As long as we still have your attention, take the time to review our recommended practices on securing built-in administrator accounts in Active Directory. Implementing these changes goes a long way towards securing your environment.

Thanks for reading, and I hope you find this helpful!

Hello there, this is Benjamin Morgan, and I’m a Premier Field Engineer covering Active Directory and Platforms related topics.  This is my first blog post I hope you are all as excited about this as I am! Today I wanted to talk with you about a couple of quick ways for querying system memory (and provide some background as to *why* I was doing this).  Well without further ado let’s get started…

Pre-Amble

Recently I was working with a customer and they had an interesting problem. They were having an issue retrieving specific user attributes from Active Directory using PowerShell. While building the command in a lab the original syntax that I was given was: Get-ADUser -filter * -properties *

Well, as we all know, friends don’t let friends use ” -filter * -properties *” because it will return everything about everything, or in this case everything about all AD users, whereas best practice is to fine tune your scripts so you’re not wasting resources on information that is not needed and will never be used. Needless to say, the script would run for a little bit then bomb out.

My first step was to obviously change the “-filter *” to “-filter ‘name -like “*”‘ but leave the “-properties *” so we could identify the exact attributes that were needed. After this change the script ran a little longer but continuously bombed out. After running the script several times and it continuously failed at the same point, after retrieving user X, my first instinct was that maybe the user right after user X had a corrupted property so I needed to determine what user was next and then see what was going on with their account. I knew that I could do a “for-each” loop, but I didn’t want to take the time to do this since the customer was on a time crunch. I modified the “-properties” statement to only return the attributes that were needed and hoped for the best knowing that if all else failed I would do a “for-each” statement and get the information that way. I then changed the PowerShell command to ‘Get-ADUser -filter ‘name -like “*”‘ -properties PasswordNotRequired’ and that command worked. After looking at the user accounts full properties that were directly after the user that it failed on, and everything returned correctly I knew that there was something else going on, but they had the information they needed so all was good. So, the real question was what was going on and why was it happening.

Before we go on, its important to be aware that the recommendation for domain controllers is to have enough memory to store the dit file in memory, the OS requirements, and enough for any third party applications installed on the DC; in other words, the file size for the dit, plus ~15-20% for the OS (you can read more on this here: https://social.technet.microsoft.com/wiki/contents/articles/14355.capacity-planning-for-active-directory-domain-services.aspx). In this situation, these best practices weren’t followed, so the added burden of parsing all of their users caused the DC to essentially hang and did not allow PowerShell to return all the requested information when using wildcards.

Problem/Solution

I knew that since the AD user attributes were good, it had to be something simple, right? Next, I started looking at the domain controller performance. All I had was PowerShell access with no actual rights to do anything except what was given to me by the PowerShell credentials of the person logged into the computer. (This was a server Admin, not a Domain Admin account…) I decided that since they were a fairly large environment, I might want to check the resources on the domain controller I was connected to. This account had rights to log into the DC! That’s a security topic that is discussed in the PAW solution https://docs.microsoft.com/en-us/windows-server/identity/securing-privileged-access/privileged-access-workstations. I figured that the first resource to look at was RAM. A domain controller should have more memory instead of less, and I knew that PowerShell could pull everything but I wasn’t sure how to get everything that I needed. So off to Bing I went… After some research the best way to get the information was to leverage WMI. The issue I encountered was that WMI returns the results in bytes, which is useless to me. Luckily, PowerShell can do just about anything! It can natively convert bytes to GB, KB, MB, or anything else you may want. I am still trying to figure out how to have it make me coffee in the morning though.

I used the Get-WMIObject cmdlet because the customer was still using Windows 7 with PowerShell 2.0. If you are using PowerShell 3.0 or above then you can use Get-CimInstance which is the more modern way of retrieving this information. The Scripting Guy has a good blog comparing and contrasting Get-WMIObject and Get-CimInstance, https://blogs.technet.microsoft.com/heyscriptingguy/2016/02/08/should-i-use-cim-or-wmi-with-windows-powershell/. The scripts were also ran locally for the purpose of putting together this blog but the commands can be ran via the PowerShell remoting ability of your choice. The following link explains the different PowerShell remoting options, https://technet.microsoft.com/en-us/library/gg981683.aspx.

The first command is Get-WMIObject win32_ComputerSystem which returns an output like the following

Or you can use Get-CimInstance win32_ComputerSystem | format-list which returns an output like the following

So TotalPhysicalMemory doesn’t do a lot of good unless you want to do the conversion to GB yourself but as I said PowerShell is smart enough to be able to do that for me.

According to https://technet.microsoft.com/en-us/library/ee692684.aspx to do the conversion the command is followed by “/ 1GB” so the command would be Get-WMIObject win32_ComputerSystem | foreach {$_.TotalPhysicalMemory /1GB}, but while this command will return the amount of memory in GB it will be in decimal notation and will look like

Get-CimInstance win32_ComputerSystem | foreach {$_.TotalPhysicalMemory /1GB}

To truncate the decimal places and only show whole numbers you have to call the .NET framework’s System.Math class ([math]). That command would be,

Get-WMIObject win32_ComputerSystem | foreach {[math]::truncate($_.TotalPhysicalMemory /1GB)}

Get-CimInstance win32_ComputerSystem | foreach {[math]::truncate($_.TotalPhysicalMemory /1GB)}

While this command returns showing my system only has 3GB, in reality it has 4GB, this is due to truncating the amount of memory that is shown to remove all decimal points and only show whole numbers.

In order to see the exact amount of memory you want to round the TotalPhysicalMemory to the nearest whole number. The command to do this is,

Get-WMIObject win32_ComputerSystem | foreach {[math]::round($_.TotalPhysicalMemory /1GB)}

Get-CimInstance win32_ComputerSystem | foreach {[math]::round($_.TotalPhysicalMemory /1GB)}

Hopefully this helps you hunt down some of those pesky memory issues, and thanks for reading!

Hi Everyone, this is Jerry Devore back with a follow-up topic from my previous post on Privileged Administrative Workstations (PAW) which is a hardened device configuration used to protect privileged credentials. In that post, I mentioned that it is possible to use IPsec to ensure an admin can only make a RDP connection to Tier 0 devices (domain controllers) from a PAW. By imposing this restriction, we limit the risk of exposing highly privileged credentials to a keyboard logger on a less trusted system such as an administrator’s standard workstation. An additional benefit is that we restrict how stolen credentials can be used unless an administrator’s PAW is also acquired.

Why IPSec?

When I explain this concept to customers I am often asked why not simply use firewall rules and avoid the complexity of IPsec. If your PAWs are going to always have the same IP address you could implement a firewall rule which restricts port TCP 3389 to a defined list source IP addresses. However, for most organizations the PAW is somewhat portable. Therefore, we need to combine firewall rules with the authentication protocols in IPsec which allows us to build “identity based firewall rules”.

Getting Started

If you have ever tried to get your head around Microsoft’s implementation of IPsec you know the learning curve can be steep. My goal in this post is not to make you an IPsec expert but rather help you quickly understand one way it can be used to improve your security posture. To get started, lets cover some basic concepts:

• A prerequisite for Microsoft’s implementation of IPsec is that the Windows Firewall must be enabled. Some 3rd party AV products are not designed to coexist with the Windows Firewall so make sure that is not a show stopper for you.
• Another prerequisite is UDP 500 which is used during the key exchange process (IKE) phase. We will not be tunneling or encrypting traffic so your security team will still be able to perform packet inspection if necessary. In fact, a network capture will pretty much look the same with the exception of the IKE handshake.
• In order for two computers to establish an IPsec connection, they must agree on parameters such as IP address ranges, authentication methods and ports. Those parameters are configured on both sides of the connection using a Connection Security Rule (CSR).
• Once two computers have successfully agreed on the parameters in the CSR, they establish a Security Association (SA) which involves authenticating each other, exchanging keying material and agreeing on encryption \ hashing algorithms.

Now that we have those basics down let’s take look at the steps required to set up a port restriction via IPsec. For this demo, I have set up two domain controllers in a lab along with a PAW workstation.

Connection Security Rule

While the configuration of the Connection Security Rule could be completed using just the Window Firewall with Advanced Security MMC, we are going work smart by creating a GPO. Once you have created a new policy browse to Computer Configuration \ Windows Settings \ Security Settings \ Windows Firewall with Advanced Security right click and select Properties.

Disclaimer: a misconfigured CSR is an excellent way to blow a Windows device off the network. If you use a GPO to deliver incorrect CSR settings, undoing the damage will require a console visit to each impacted device.

On properties page change the Firewall state to On (recommend) for the Domain Profile. Also set Inbound connections to Block (default) and Outbound connections to Allow (default). While these setting do not configure IPsec, configuring them will ensure that the Windows Firewall will be on.

Next right click Connection Security Rules and select New Rule.

As you can see from the wizard there are several ways to leverage Microsoft’s implementation of IPsec. Given we are only interested in implementing a port restriction, select Custom and we will save the other rule types for another blog post.

On the Endpoints page we identify sides of the network connection. It does not matter which side of the network you define as Endpoint 1 or Endpoint 2 until later in the wizard when we associate Endpoints with a port. My lab has two domain controllers. I have set their IP addresses for Endpoint 1. The address of my PAW is dynamic, so I set Endpoint 2 to Any IP Address.

The next page defines the authentication requirements. For this scenario select Request authentication for inboard and outbound connections. With that option the devices which share this connection agreement will attempt to negotiate IPsec but if the negotiation fails, the devices will continue to communicate. If you think that does not seem very secure keep reading until we get to the firewall rule section.

The next page of the wizard is where the Authentication Method is defined. Keep in mind we are leveraging IPsec so the identity of the Computer can be known when the connection is made. In order to have the option to also restrict the connection based on the user account, select Computer and user (Kerberos V5).

On the Protocol and Ports page scope the IPsec connection to port 3389 for Endpoint 1 port. While the solution will work if All Ports is selected, doing that would cause the domain controllers to attempt to negotiate IPsec for all connections which generates unnecessary overhead.

The PAW will use a random high source port for the RDP connection rather than 3389 so Endpoint 2 port should be set to All Ports.

The next page associates the CSR with Windows Firewall profiles. Under normal circumstances only the Domain profile is required. However, there are conditions which could cause the Network Location Awareness service to not select the Domain Profile. To error on the side of safety and stability, I suggest selecting all three profiles.

In the last page of the wizard give the rule a name and description then click Finish to save the settings.

That does it for the Connection Security Rule but we are not done yet. We still need to configure the inbound firewall rule for RDP to require IPsec and filter the connection based on security principles. Like the CSR, the inbound firewall rule can be configured directly on the server or in a GPO.

Inbound Firewall Rule

On the domain controller open the properties of the Remote Desktop – User Mode (TCP-In) inbound rule and select the General page. The Action setting is where the firewall rule is bound to IPsec. By selecting Allow the connection if it is secure, the firewall rule will not allow the inbound connection unless an IPsec connection has been successfully established. The use of this rule is why we’re able to set the Connection Security Agreement to Request authentication rather than Require.

Clicking the Customize button provides the ability to configure additional requirements for the IPsec connection. The first two options allow us to prevent the packets from being read (encrypted) or modified (integrity-protected) by a Man in the Middle (MITM). While enabling those features improves security, they also add network dependencies. Given this solution is targeted at securing the endpoint rather than the packets, I recommend selecting Allow the connection to use null encapsulation. This is the setting which will allow the security team to continue to perform network inspection if they have that requirement.

On the Remote Users page we can define users or groups of users which are allowed to pass through the rule. This might seem a little redundant since permissions should already be set on the Remote Desktop service. However, a key concept in security is “Defense in Depth” which means there should be multiple layers of overlapping defenses in case one fails.

The last item we need to configure is the Authorized computers on the Remote Computers page. This is a key setting because it ensures the Tier 0 admins can only use their PAW devices when making an RDP connection to the domain controller.

Before we test our solution lets run through a quick checklist:

• Connection Security Rule GPO linked to the OU of the Domain Controller and PAW
• Firewall enabled on the Domain Profile of both computers
• Test client added to the PAW Computers domain group
• User account has been added to Tier 0 Admin domain

If it has been configured correctly, testing the solution will not look any different than a normal RDP connection. So how do we know if it is working correctly? We do that by confirming the Security Associations where successfully created after a connection is made. Open Windows Firewall with Advanced Security MMC (wf.msc). Under Monitoring \ Security Associations you will see Main Mode and Quick Mode.

During the Main Mode phase of the Security Association the devices establish a secure channel and exchange keying material.

In the Quick Mode phase the devices negotiate how the data exchanged will be protected. Since we selected Allow the connection to use null encapsulation in the firewall rule, Quick Mode SA did not establish Integrity or Encryption values.

One last test of our solution is to confirm devices not in the PAW Computers group cannot make a connection. Given the firewall rule will block the connection, there will be no response on 3389 when the connection is attempted.

To quote Porky Pig … “That’s All Folks”. I hope this information helps in your journey to protect your privileged credentials. If this post has you thinking about giving the Windows Firewall a second look, I recommend you check out my friend Jessica’s Ignite presentation.

Hi, this is Michael Koeppl again. I’m with the Premier Mission Critical (PMC) Team and assisting customers when they hit OS issues in their critical infrastructure, and today I wanted to talk with you about an interesting Windows Backup issue I encountered.

My customer realized that his System State Backups (https://technet.microsoft.com/en-us/library/cc938537.aspx) on one of his DCs stopped working and asked if I could have  a look.

In the Application Event Log was a prominent VSS error saying something about a ConvertStringSidToSid function which failed.

Here’s the original text for better searchability:

Log Name:      Application
Source:        VSS
Date:          27.06.2017 21:00:21
Event ID:      8193
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      MYcomputer.anydomain.net

Description:
Volume Shadow Copy Service error: Unexpected error calling routine ConvertStringSidToSid(S-1-5-21-2828234547-00000000000-1509355905-1125.bak).  hr = 0x80070539,
The security ID structure is invalid.

Operation:
OnIdentify event
Gathering Writer Data

Context:
Execution Context: Shadow Copy Optimization Writer
Writer Class Id: {4dc3bdd4-ab48-4d07-adb0-3bee2926fd7f}
Writer Name: Shadow Copy Optimization Writer
Writer Instance ID: {74a61a33-665e-4041-b325-726825b2bf8e}

This was followed by a 521 Event from Windows Backup telling you that the Backup operation failed.

Why?

The hint was already in the event details from the VSS error:

ConvertStringSidToSid(S-1-5-21-2828234547-00000000000-1509355905-1125.bak)

Can you spot the SID with the BAK extension at the end?

So we looked at the ProfileList regkey on that machine.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList

And here it is:

We followed this KB (947215) and ultimately removed the Profile with the BAK extension and started another Windows SystemState Backup, which succeeded without any errors.

The User Profile Service failed the logon. User profile cannot be loaded
http://support.microsoft.com/kb/947215/en-us

Here’s an automated way to clean up the old profiles from that list.

Script to fix issues described in KB947215 (PowerShell)

https://gallery.technet.microsoft.com/scriptcenter/Script-to-fix-issues-ab65f43e

Hope you enjoyed the quick excursion from VSS to profiles with an easy solution at the end.

Greetings,

Michael