Special thanks to Brian Lich and Ajay Sarkaria for helping build the list.

Until next time,

| Kaushik Ainapure
| Solution Asset Program Manager
| Windows & Azure

Setting up a source-initiated subscription where the event sources are in the same domain as the event collector computer

1. Run the following command from an elevated privilege command prompt on the Windows Server domain controller to configure Windows Remote Management:winrm qc -q 
2. Start group policy by running the following command:%SYSTEMROOT%\System32\gpedit.msc 
3. Under the Computer Configuration node, expand the Administrative Templates node, then expand the Windows Components node, then select the Event Forwarding node.
4. Right-click the SubscriptionManager setting, and select Properties. Enable the SubscriptionManager setting, and click the Show button to add a server address to the setting. Add at least one setting that specifies the event collector computer. The SubscriptionManager Properties window contains an Explain tab that describes the syntax for the setting.
5. After the SubscriptionManager setting has been added, run the following command to ensure the policy is applied:gpupdate /force 

1. Run the following command from an elevated privilege command prompt on the Windows Server domain controller to configure Windows Remote Management:winrm qc -q 
2. Run the following command to configure the Event Collector service:wecutil qc /q 
3. Create a source initiated subscription. This can either be done programmatically, by using the Event Viewer, or by using Wecutil.exe. For more information about how to create the subscription programmatically, see the code example in Creating a Source Initiated Subscription. If you use Wecutil.exe, you must create an event subscription XML file and use the following command:wecutil cs configurationFile.xmlThe following XML is an example of the contents of a subscription configuration file that creates a source-initiated subscription to forward events from the Application event log of a remote computer to the ForwardedEvents log on the event collector computer.

   XML <Subscription xmlns="http://schemas.microsoft.com/2006/03/windows/events/subscription"> <SubscriptionId>SampleSISubscription</SubscriptionId>     <SubscriptionType>SourceInitiated</SubscriptionType>     <Description>Source Initiated Subscription Sample</Description> <Enabled>true</Enabled> <Uri>http://schemas.microsoft.com/wbem/wsman/1/windows/EventLog</Uri>     <!-- Use Normal (default), Custom, MinLatency, MinBandwidth --> <ConfigurationMode>Custom</ConfigurationMode>     <Delivery Mode="Push"> <Batching> <MaxItems>1</MaxItems>             <MaxLatencyTime>1000</MaxLatencyTime> </Batching> <PushSettings> <Heartbeat Interval="60000"/> </PushSettings> </Delivery>     <Expires>2018-01-01T00:00:00.000Z</Expires>     <Query> <![CDATA[ <QueryList> <Query Path="Application"> <Select>Event[System/EventID='999']</Select> </Query> </QueryList> ]]> </Query>     <ReadExistingEvents>true</ReadExistingEvents> <TransportName>http</TransportName> <ContentFormat>RenderedText</ContentFormat> <Locale Language="en-US"/> <LogFile>ForwardedEvents</LogFile> <AllowedSourceNonDomainComputers></AllowedSourceNonDomainComputers> <AllowedSourceDomainComputers>O:NSG:NSD:(A;;GA;;;DC)(A;;GA;;;NS)</AllowedSourceDomainComputers> </Subscription>

   Note  When creating a source initiated subscription, if AllowedSourceDomainComputers, AllowedSourceNonDomainComputers/IssuerCAList, AllowedSubjectList, and DeniedSubjectList are all empty, then "O:NSG:NSD:(A;;GA;;;DC)(A;;GA;;;NS)" will be used as the default security descriptor for AllowedSourceDomainComputers. The default descriptor grants members of the Domain Computers domain group, as well as the local Network Service group (for the local forwarder), the ability to raise events for this subscription.

1. On the event collector computer complete the following steps:
   • Run the following command from an elevated privilege command prompt on the Windows Server domain controller to get the runtime status of the subscription:wecutil gr <subscriptionID> 
   • Verify that the event source has connected. You might need to wait until the refresh interval specified in the policy is over after you create the subscription for the event source to be connected.
   • Run the following command to get the subscription information:wecutil gs <subscriptionID> 
   • Get the DeliveryMaxItems value from the subscription information.
2. On the event source computer, raise the events that match the query from the event subscription. The DeliveryMaxItems number of events must be raised for the events to be forwarded.
3. On the event collector computer, validate that the events have been forwarded to the ForwardedEvents log or to the log specified in the subscription.

Setting up a source initiated subscription where the event sources are not in the same domain as the event collector computer

1. On the event collector computer, run the following commands from an elevated privilege command prompt to configure Windows Remote Management and the Event Collector service:winrm qc -qwecutil qc /q  
2. The collector computer should have a server authentication certificate (certificate with a server authentication purpose) in a local computer certificate store.
3. On the event source computer, run the following command to configure Windows Remote Management:winrm qc -q 
4. The source machine should have a client authentication certificate (certificate with a client authentication purpose) in a local computer certificate store .
5. Port 5986 is opened on the event collector computer. To open this port, run the command:netsh firewall add portopening TCP 5986 "Winrm HTTPS Remote Management"

• A server authentication certificate has to be installed on the Event Collector computer in the Personal store of the Local machine. The subject of this certificate has to match the FQDN of the collector.
• A client authentication certificate has to be installed on the Event Source computers in the Personal store of the Local machine. The subject of this certificate has to match the FQDN of the computer.
• If the client certificate has been issued by a different Certification Authority than the one of the Event Collector then those Root and Intermediate certificates needs to be installed on the Event Collector as well.
• If the client certificate was issued by an Intermediate certification authority and the collector is running Windows 2012 or later you will have to configure the following registry key:HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\ClientAuthTrustMode (DWORD) = 2Find more information in this article: https://technet.microsoft.com/en-us/library/dn786429(v=ws.11).aspx

1. Set the certificate authentication with the following command.winrm set winrm/config/service/auth @{Certificate="true"}
2. A WinRM HTTPS listener with the server authentication certificate thumb print should exist on the event collector computer. This can be verified with the following command: winrm e winrm/config/listener
3. If you do not see the HTTPS listener, or if the HTTPS listener's thumb print is not same as the thumb print of the server authentication certificate on collector computer, then you can delete that listener and create a new one with the correct thumb print.To delete the https listener, use the following command:winrm delete winrm/config/Listener?Address=*+Transport=HTTPS To create a new listener, use the following command: winrm create winrm/config/Listener?Address=*+Transport=HTTPS @{Hostname="<FQDN of the collector>";CertificateThumbprint="<Thumb print of the server authentication certificate>"}

1. Create new local user and add it to the local Administrators group.
2. Create the certificate mapping using a certificate that is present in the machine’s “Trusted Root Certification Authorities” or “Intermediate Certification Authorities”. This is the certificate of the Root or Intermediate CA that issued the certificates installed on the Event Source computers.winrm create winrm/config/service/certmapping?Issuer=<Thumbprint of the issuing CA certificate>+Subject=*+URI=* @{UserName="<username>";Password="<password>"} -remote:localhost
3. From a client test the listener and the certificate mapping with the following command:winrm g winrm/config -r:https://<Event Collector FQDN>:5986 -a:certificate -certificate:"<Thumbprint of the client authentication certificate>"This should return the WinRM configuration of the Event collector. Do not move past this step if the configuration is not displayed. What happens at this step?
   • The client connects to the Event Collector and sends the specified certificate
   • The Event Collector looks for the issuing CA and checks if the is a matching certificate mapping
   • The Event Collector validates the client certificate chain and revocations status
   • If the above steps succeeds the authentication is completed.

1. Open Event Viewer in the Event Collector and navigate to the Subscriptions node.
2. Right-click Subscriptions and choose “Create Subscription…”
3. Give a name and an optional description for the new Subscription.
4. Select “Source computer initiated” option and click “Select Computer Groups…”.
5. In Computer Groups click on “Add Non-Domain Computers…” and type the event source hostname.
6. Click “Add Certificates…” and add the certificate of the Certification authority that issue the client certificates. You can click in View Certificate to validate the certificate.
7. In Certificate Authorities click OK to add the certificate.
8. When finished adding Computers click OK.
9. Back to the Subscription Properties, click in Select Events...
10. Configure the Events Query Filter by specifying the event level(s), event log(s) or event source(s), the event ID(s) and any other filtering options.
11. Back to the Subscription Properties, click on Advanced...
12. Choose one of the optimization options for event delivery from the Source Event to the Event Collector, or leave the default Normal:
    1. Minimize Bandwidth: Events will be delivered will less frequency to save bandwidth.
    2. Minimize Latency: Events will be delivered as soon as they occur to reduce events latency.
13. Change the Protocol to HTTPS and click OK.
14. Click OK to create the new subscription.
15. Check the runtime status of the Subscription by right-clicking and choosing “Runtime Status”

1. Open the Certificates management console for Local machine on the Event Source computer
2. Right click on the client certificate then Manage Private keys
3. Grant Read permission to the NETWORK SERVICE user

1. Logon with an administrator account and open the Local Group Policy Editor (gpedit.msc)
2. Navigate to the Local Computer Policy\Computer Configuration\Administrative Templates\Windows Components\Event Forwarding.
3. Open “Configure the server address, refresh interval, and issuer certificate authority of a target Subscription Manager” policy.
4. Enable the policy and click the SubscriptionManagers “Show...” button.
5. In the SubscriptionManagers window enter the following string: Server=HTTPS://<FQDN of the Event Collector server>:5986/wsman/SubscriptionManager/WEC,Refresh= <Refresh interval in seconds>,IssuerCA=< Thumbprint of the issuing CA certificate>
6. Run the following command line to refresh Local Group Policy settings:Gpupdate /force
7. These steps should produce event 104 in your source computer Event Viewer Applications and Services Logs\Microsoft\Windows\Eventlog-ForwardingPlugin\Operational log with the following message: "The forwarder has successfully connected to the subscription manager at address <FQDN>.",followed by event 100 with the message: "The subscription <sub_name> is created successfully."
8. On the Event Collector, the Subscription Runtime Status will show now 1 Active computer.
9. Open the ForwardedEvents log on the Event Collector and check if you have the events forwarded from the Source computers.

Deploying Group Policy Security Update MS16-072 \ KB3163622
https://blogs.technet.microsoft.com/askds/2016/06/22/deploying-group-policy-security-update-ms16-072-kb3163622/

Please keep in mind that the latest changes/updates will be in the original blog post mentioned above.

Thanks,
| Kaushik Ainapure
| Solution Asset Program Manager
| Windows & Azure

We have seen a surge in support cases where the Windows firewall service crashes if the firewall logging for dropped and allowed connections is enabled on Windows 8.1 or Windows Server 2012 R2.

Symptoms include:

• The SVCHOST instance containing Windows Firewall Service (mpssvc) Crashes on Windows 8.1 / Windows Server 2012 R2
• Applications that talk to the Firewall Service hang, stop responding or crash because the Firewall service is hung
• If the Windows Server 2012 R2 also has the DirectAccess role installed, you may notice that the DirectAccess clients get disconnected as the Windows Firewall Service crashes on the DirectAccess Server
• The Windows firewall service crash may impact all L2TP VPN and IPSEC connections affecting both Clients and Servers
• On multiple Windows Server 2012 R2 cluster systems, Cluster Shared Volumes may sporadically go into a Paused State (Event ID 5120) with the error code c000020c STATUS_CONNECTION_DISCONNECTED.  This may result in the crash of the virtual machines which are hosted on these CSVs. All the CSVs may be impacted, not just one specifically

If you are experiencing this issue, please install the update that is described in the following Knowledge Base article:

3155768 Firewall service freezes and crashes if the firewall logging is enabled in Windows

Until next time!

Ajay Sarkaria
Supportability Program Manager – Windows

You can download the package from the following link:

Administrative Templates (.admx) for Windows Server 2016 Technical Preview 5

These .admx files can be used to create a central store in SYSVOL.
For more details, visit the following Knowledge Base article:

3087759 How to create and manage the Central Store for Group Policy Administrative Templates in Windows

For information on references and settings, use the following link to download the spreadsheets:

Group Policy Settings Reference for Windows and Windows Server

until next time,

Thanks,

Ajay Sarkaria
Supportability Program Manager – Windows

• You are running Windows Server 2008 R2 Servers as Domain Controller and/or DNS Servers and
• You install MS15-127: Security update for Microsoft Windows DNS to address remote code execution: December 8, 2015 (https://support.microsoft.com/en-us/kb/3100465)

AND/OR

• You install the following hotfix: 3022780 DNS server does not respond with IP address to a CNAME query for a delegated zone in Windows Server 2008 R2

1. The domain DNS Zones do not load
2. DNS Server manager may display the message: "The Zone is being read into memory"

Event Type: Warning Event Source: DNS Event Category: None Event ID: 4019 Date:  <Date> Time:  <Time> User:  N/A Computer: SERVER.contoso.com Description: The DNS server attempted to load the Active Directory-integrated zone contoso.com in the background but there was an error during load. This zone will now be shut down. Correct the error and restart the DNS server service. The event data contains the error.

dnscmd /Config /DsMinimumBackgroundLoadThreads 0

dnscmd /Config /DsMinimumBackgroundLoadThreads 1

---------------

My name is Ajay Sarkaria & I am a Supportability Program Manager at Microsoft. I want to highlight an issue you may experience if you are using LBFO Dynamic Team mode on Windows Server 2012 R2 Servers.

NIC teaming is available in all editions of Windows Server 2012 R2 including Server Core. NIC teaming in Windows Server 2012 R2 supports the following traffic load distribution algorithms:
  

• Hyper-V switch port
• Address Hashing
• Dynamic

Dynamic teaming load balancing is a new feature in Windows Server 2012 R2. Windows 2012 R2 Servers defaults to dynamic modewhen creating teaming NICs on physical computers.

This algorithm takes the best aspects of each of the other two modes and combines them into a single mode.

• Outbound loads are distributed based on a hash of the TCP Ports and IP addresses. Dynamic mode also rebalances loads in real time so that a given outbound flow may move back and forth between team members.
• Inbound loads are distributed as though the Hyper-V port mode was in use

The outbound loads in this mode are dynamically balanced based on the concept of flowlets. Just as human speech has natural breaks at the ends of words and sentences, TCP flows (TCP communication streams) also have naturally occurring breaks. The portion of a TCP flow between two such breaks is referred to as a flowlet. When the dynamic mode algorithm detects that a flowlet boundary has been encountered, i.e., a break of sufficient length has occurred in the TCP flow, the algorithm will opportunistically rebalance the flow to another team member if appropriate. The algorithm may also periodically rebalance flows that do not contain any flowlets if circumstances require it. As a result, the affinity between TCP flow and team member can change at any time as the dynamic balancing algorithm works to balance the workload of the team members.

There is a scenario where LBFO may drop send packets when using the default dynamic mode. Packet loss increases as processor cores are added and network traffic increases.

Windows Server 2012 R2 computers configured with teaming NICS in Dynamic mode may experience the following symptoms:

• Cluster nodes are unexpectedly removed from cluster groups
• SQL servers experience database transaction failures
• TCP connection aborts

LBFO Event 8 may be logged in the LBFO Event Log:

Event location: [Applications and Services] -> [Microsoft] -> [MsLbfoProvider] –> [Operational] view

Log Name: Microsoft-Windows-MsLbfoProvider/Operational
Source: Microsoft-Windows-MsLbfoEventProvider
Event ID: 8
Level: Warning
Keywords: (4398046511104),(1099511627776)
Computer: SERVER.contoso.com
Description:
Failing NBL send on TeamNic <some value>

Microsoft-Windows-FailoverClustering events 1177 and 1135 may be logged
Note: these events may be caused by dropped packets or other root causes

If you are using LBFO in the default Dynamic mode and are experiencing the above symptoms, the following workaround may provide relief till we work on a public fix to be released:

• Use another teaming mode other than Dynamic Active-Active such Dynamic Active-Standby or Address Hash mode. 
• If you have only two NIC adapters as part of LBFO team then make one of the adapters as Standby adapter.

Screenshot

Note:The workarounds may have an impact like reduced network throughput / network performance so follow these in case you have the above symptoms and are using LBFO in the default dynamic mode. Once we have a public fix released, we will update the blog with the public KB details. It is highly recommended you change the mode back to dynamic after you install the fix.

As a general recommendation when using LBFO always use the latest network interface card (NIC) driver \ firmware versions. You can check for the latest driver \ firmware versions on your OEM or NIC Vendor websites.

Thanks,

Ajay Sarkaria
Supportability Program Manager - Windows

If you need more details on the specific vulnerabilities disclosed, please see https://tools.cisco.com/security/center/publicationListing.x.

We will update this post as we get further through our review.

Customers can configure a probe to perform health detection on of a particular instance by probing a specified port.  There are two types of probes: TCP and HTTP.

Example configuring probe via the portal:

Configuring a probe via PowerShell example:

PS C:\> Set-AzureLoadBalancedEndpoint -ServiceName "ContosoService" -LBSetName "LBSet01" -Protocol "TCP" -LocalPort 80 -ProbeProtocolTCP -ProbePort 8080 -ProbeIntervalInSeconds 40 -ProbeTimeoutInSeconds 80

Example via csdef (Paas): LoadBalancerProbes

The number of successful / failed probes required to mark an instance up or down is calculated for the user.  This is SuccessFailCount value is equal to the timeout divided by probe frequency. For portal, the timeout is set to two times the value of frequency (timeout = frequency * 2).

HTTP based probes perform an HTTP GET request against the specified (relative) URL. The probe marks the role instance down when:

1. The HTTP application returns a HTTP response code other than 200 (i.e. 403, 404, 500, etc.). This is considered a positive acknowledgment that the application instance wants to be taken out of service right away.
2. In the event the HTTP server does not respond at all after the timeout period. Note that depending on the timeout value set, this might mean multiple probe requests go unanswered before marking probe as down (i.e. SuccessFailCount probes are sent).
3. When the server closes the connection via a TCP reset.

TCP based probes initiate a connection by performing a three way handshake. TCP based probes mark the role instance down when:

1. In the event the TCP server does not respond at all after the timeout period. Note that depending on timeout value set, this might mean multiple probe requests go unanswered before marking probe as down (i.e. SuccessFailCount probes are sent).
2. A TCP reset is received from the role instance. 

TCP and HTTP probes are considered healthy and mark the role instance as UP when:

1. Upon the first time the VM boots and the LB gets a positive probe
2. The number of successful probes meets the threshold required by the number SuccessFailCount (see above) to mark the role instance as healthy. If a role instance was removed, SuccessFailCount in a row successful probes are required to mark role instance as UP.

 If the health of a role instance is fluctuating, the Azure Load balancer is waits longer before putting the role instance back in the healthy state. This is done via policy to protect the user and the infrastructure.

 Additionally, the probe configuration of all load balanced instances for an endpoint (load balanced set) must be the same.  This means you cannot have a different probe configuration (i.e. local port, timeout, etc.) for each role instance or virtual machine in the same hosted service for a particular endpoint combination.