Blocked traffic on a public IP on a Load balancer



You setup a new Load balancer with public IP(s) for incoming traffic, but when testing, all incoming traffic is blocked. No reason, its just blocked.

(Resolution at the end…)

Azure based environment.
An appliance (or a VM) with one or two NIC’s connected to a public IP

Add a NSG to the public IP’s…and specifically allow the traffic you want to allow, if you don’t care, add from any to any port *
If you don’t add an NSG to the NIC, traffic to the Public IP will be blocked…it just is.

Azure Firewall SNAT private IP address ranges

Deploy an Azure Firewall with multiple public IP addresses using Azure PowerShell

Thanks to:
Thomas Vuylsteke – Microsoft Azure Fasttrack team
Microsoft Premier Support
Akelius Residential Property AB (Martin Supan, Mattias Segerström)




 Thomas Odell Balkeståhl on LinkedIn


Enable Azure Update Management in Azure Firewall


When you have Windows VM’s in an Azure network and internet traffic is routed through your Azure Firewall, and you need to allow them to update, either with Automatic updates, or Azure Update management. There are a few things you need to allow to get through your FW.
Add the following rules and you will have it up and running in no time.

Go to the Azure Firewall in the Azure portal.
Rules -> Application Rule Collection
+ Add application rule collection

Rule 1
Name: Windows_Update (No whitespace)
Priority: 2000 (A number between 100-65000)
Action: Allow
Rule, FQDN Tags:
Name:Windows Update
Source Type: IP Address
Source: Prefix of vNet/Subnet or host, ex.
FQDN tags: WindowsUpdate (Select in the dropdown)

Rule 2
Name: Monitoring_Agent (No whitespace)
Priority: 2100 (A number between 100-65000)
Action: Allow
Rule, Target FQDNs:
Name:OMS Agent
Source Type: IP Address
Source: Prefix of vNet/Subnet or host, ex.
Protocol:Port: https:443
Target FQDNs: *,*,*

Rule 3
Name: Hybrid_Runbook_Worker (No whitespace)
Priority: 2200 (A number between 100-65000)
Action: Allow
Rule, Target FQDNs:
Name:Hybrid Runbook Worker
Source Type: IP Address
Source: Prefix of vNet/Subnet or host, ex.
Protocol:Port: https:443
Target FQDNs: *



FQDN tags overview

Connect Operations Manager to Azure Monitor

Hybrid Runbook Worker overview


Thanks to:
Joakim Gräns – Asurgent AB




 Thomas Odell Balkeståhl on LinkedIn


Azure Firewall and DNS forward timeout – SNAT UDP utilization at 100%



External DNS queries dropped causing timeouts and unresponsive services, web-browsing, Office 365, Windows Virtual Desktop(WVD), etc.

(Resolution at the end…)

Azure based environment.
Classic AD with a few VM based Domain controllers in Azure.
DC’s are acting as the primary DNS service for all servers, services and clients in the environment.
Azure firewall is configured as the primary firewall solution for the Azure based environments.
The subnet(s) where the DC’s are located are routed (UDR) to use the Azure Firewall for outgoing internet traffic
The DC’s IP are the added as the primary and secondary DNS for all vNets in Azure, for office subnets, VPN, etc.
DNS service on the DC’s are configured to forward external DNS queries, as is the default, either a custom Forwarder, or the DNS hints.

As the workload increases, you may notice a congestion in the Azure Firewall, at a certain amount of external forwarded DNS queries, the Azure Firewall will choke at 100%.
You may notice this as a user, when simple internet pages in a browser no longer opens, if you use WVD, the environment may stop responding all together due to the lack of DNS service in the WVD hostpool.
As an admin, you may see that a repeated number of NSLOOKUP to an external address, will result in intermittent timeouts.

Azure Firewall.
A part of the DNS service is that it uses UDP, and Azure Firewall uses SNAT for address translation from every internal source, resulting in every UDP request from one IP to an external provider (,, etc.) will use one port out of the 65.000 available in the TCP protocol for that unique destination. When the number of DNS requests to the same address (say gets repeated, every request gets its own port, and after a while, all 65.000 are taken. Causing congestion in the Firewall and it starts to drop requests. Two requests to and two to will thus result in 4 ports being used, while single requests to 1000 different addresses will only use the one port.

In our case, we saw that during office hours, after enough users and systems were migrated, the Firewall reached 100% in UDP SNAT utilization, causing timeouts on our DNS servers (DC’s) causing services and systems to fail.

Issue can clearly be seen starting at the beginning of day on Thursday July 2nd, then on Friday July 3rd, stopped over the weekend, then up again on Monday July 6th. The graph also shows that we have users in Europe as well as in America, which prolongs the period a bit.

After some t-shooting, severity A case with Microsoft premier support and help from Microsoft FastTrack, we had two ways to quickly mitigate the problem and get the services operational again.


  1. For us, the fastest we could implement, was to add a second public IP on the Azure Firewall, doubling the amount of ports used for SNAT to 130.000 (65.000 x2). REMEMBER, you cannot control what goes to what port, so if any of your internal servers or systems connect to an external service, and the Azure Firewalls public IP is whitelisted, you have to add this second IP to the whitelist as well. Every place that has it whitelisted. This because Azure Firewall randomly selects the public IP to use for outgoing traffic.
    This immediately reduced the UDP SNAT util from 100%+ to 60-70%

    The utilization quickly dropped, to about 60-70%
  2. The best solution, which we implemented a few minutes later, is to add Microsofts Azure ‘public’ DNS IP as the forward DNS server on our DNS servers (the DC’s). This is an Azure Datacenter service, and as such, it will be recognized and accesses using the Azure backbone and never going through the Azure Firewall at all. This reduced the load from 60-70% on UDP SNAT to 0%!
    The IP to use is: (This will only be accessible from Azure environments, do NOT use on onprem DNS servers!)

    The utilization here dropped completely to 0%, since all DNS queries now go to the Azure ‘internal’ DNS

Microsoft Azure DNS IP:


Azure Firewall SNAT private IP address ranges

Deploy an Azure Firewall with multiple public IP addresses using Azure PowerShell

Thanks to:
Thomas Vuylsteke – Microsoft Azure Fasttrack team
Microsoft Premier Support
Akelius Residential Property AB (Martin Supan, Mattias Segerström)




 Thomas Odell Balkeståhl on LinkedIn


TCP/IP Ports of SharePoint 2016

SharePoint 2016 huh?!
(Long time since I last posted anything real here…)

Actually, this post is by popular demand 🙂 This is the 2016 version of the post a wrote when SHarePoint 2013 was new, as you can see, not much has changed…I have updated a few lines with what I know now that I did not know then, thats it. Please let me know if I missed something.

The recommended approach is to create a GPO with these firewall rules and apply that rule to the SharePoint servers in your farm. Add all of them, best that way to avoid extreme t-shooting in the future.

Another but related recommendation is to configure the Loopback check funktion in Windows server to allow the FQDN’s of your web applications (Use the Loopback check tool).

List of ports used by SharePoint 2013 and its related services.
Reference links at the end.

Protocol Port Usage Comment
TCP 80 http Client to SharePoint web server traffic
(SharePoint – Office Online Server/Office Web Apps communication)
TCP 443 https/ssl Encrypted client to SharePoint web server traffic
(Encrypted SharePoint – Office Online Server/Office Web Apps communication)
TCP 1433 SQL Server default communication port. May be configured to use custom port for increased security
UDP 1434 SQL Server default port used to establish connection May be configured to use custom port for increased security
TCP 445 SQL Server using named pipes When SQL Server is configured to listen for incoming client connections by using named pipes over a NetBIOS session, SQL Server communicates over TCP port 445
TCP 25 SMTP for e-mail integration Cannot in 2016 be configured (Use SMTP ports other than the default (25).)
TCP 16500-16519 Ports used by the search index component Intra-farm only
Inbound rule Added to Windows firewall by SharePoint. (GPO may override this change)
TCP 22233-22236 Ports required for the AppFabric Caching Service Used by the Distributed Cache…
TCP 808 Search – Query processing component
Windows Communication Foundation communication
Search – Query processing component
TCP 32843 Communication between Web servers and service applications http (default) To use custom port, see references section
Inbound rule Added to Windows firewall by SharePoint
TCP 32844 Communication between Web servers and service applications https
Inbound rule Added to Windows firewall by SharePoint
TCP 32845 net.tcp binding: TCP 32845 (only if a third party has implemented this option for a service application)  Custom Service Applications
Inbound rule Added to Windows firewall by SharePoint
TCP 32846 Microsoft SharePoint Foundation User Code Service (for sandbox solutions)  Inbound on all Web Servers
Inbound rule Added to Windows firewall by SharePoint
Outbound on all Web and App servers with service enabled.
TCP 636 User Profile Synchronization Service/Active Directory Import Synchronizing profiles between SharePoint 2016 and AD using SLDAP (Secure LDAP)
TCP 5725 User Profile Synchronization Service Synchronizing profiles between SharePoint 2016 and Active Directory Domain Services (AD DS)
TCP + UDP 389 User Profile Synchronization Service LDAP Service
TCP + UDP 88 User Profile Synchronization Service Kerberos
TCP + UDP 53 User Profile Synchronization Service DNS
UDP 464 User Profile Service Kerberos change password
TCP 809 Office Online Server/Office Web Apps Office Online Server/Office Web Apps intra-farm communication.


Security for SharePoint Server 2016

TCP/IP Ports of SharePoint 2013





Twitter | Technet Profile | LinkedIn

Office 365 News – OneDrive for Business now supports 10GB files and much more

 Office365logo       SP2013logo

Short story: The OneDrive for Business improvements are here!

This was promised to us a long time ago, and it has now finally come to be. At the same time, the 20.000 file limit from before has also been removed (Improved)
Here is the proof:


The file was in addition, uploaded using the new OneDrive sync client!
(Dropped the file in the local cache and let the sync do its stuff)

  • The OneDrive for Business Next Generation Sync Client is available for Windows 7, 8 and 10 (8.1 support will be added in the first quarter of 2016) and Mac OS X 10.9 and above.
  • Storage, rolling out is an increase from 1TB to 5TB, upon request, more will be made available until unlimited is achieved? (Valid for: Enterprise E3, E4 and E5, Government E3, E4 and E5, Education, OneDrive for Business Plan 2 and SharePoint Online Plan 2)
  • 10GB filesize limit
  • No more 20.000 file limit
  • !! With this first release of several, the Next Generation Sync Client supports OneDrive for Business only, but we will add support for SharePoint document libraries in future releases. (This is the best news in a long time)
  • In the interim, if customers require sync for both OneDrive for Business and SharePoint document libraries, the Next Generation Sync Client is designed to work side-by-side with the existing sync client.
  • the OneDrive for iOS app will support offline storage. You can selectively flag files for local availability and open them when disconnected
  • For developers: (OneDrive developer portal)


Read the official story on the Office 365 blog about the (then upcoming) news here:

OneDrive for Business update on storage plans and Next Generation Sync Client




Twitter | Technet Profile | LinkedIn

SharePoint Online – Missing Web Parts with custom script disabled

 Office365logo       SP2013logo

Missing Web Parts with custom script disabled…

AdminThe Custom Script setting (Default disabled)

As I have posted about before, during the end of 2014, beginning of 2015, a new security feature in SharePoint Online has been rolled out. The feature in itself is a great security feature if that is what you want.

Missing example:


Expected webparts:


Note: changes to this setting might take up to 24 hours to take effect.

In my previous post on this setting, I listed the missing features, however this is not all that will go missing. In addition, quite a few webparts will be gone from your SharePoint Online environment. This may or may not be expected by you and your users/editors/developers…
Below is the list of webparts that you will not find with the Custom script setting off/disabled.

Web part category Web part
Blog Blog Archives

Blog Notifications

Blog Tools

Business Data Business Data Actions

Business Data Item

Business Data Item Builder

Business Data List

Business Data Related List

Excel Web Access

Indicator Details

Status List

Visio Web Access

Community About This Community


My Membership


What’s Happening

Content Rollup Categories

Project Summary

Relevant Documents

RSS Viewer

Site Aggregator

Sites in Category

Term Property


WSRP Viewer

XML Viewer

Document Sets Document Set Contents

Document Set Properties

Forms HTML Form Web Part
Media and Content Content Editor

Script Editor

Silverlight Web Part

Search Refinement

Search Box

Search Navigation

Search Results

Search-Driven Content Catalog-Item Reuse
Social Collaboration Contact Details

Note Board

Organization Browser

Site Feed

Tag Cloud

User Tasks

Find Microsofts support article on the setting here:
Turn scripting capabilities on and off (Microsoft support article)

The complete list of settings affected and webparts missing: Save Site as Template, Save document library as template, Solution Gallery, Web Designer Galleries, Theme Gallery, Help Settings, Sandbox solutions, the Blog Archives, Blog Notifications, Blog tools Blog Webparts, the Business Data Actions, Business Data Item, Business Data Item Builder, Business Data List, Business Data Related List, Excel Web Access, Indicator Details, Status List, Visio Web Access Business Data Webparts, the About This Community, Join, My Membership, Tools, What’s Happening Community Webarts, the Categories, Project Summary, Relevant Documents, RSS Viewer, Site Aggregator, Sites in Category, Term Property, Timeline, WSRP Viewer, XML Viewer Content Rollup Webparts, the Document Set Contents, Document Set Properties Document Sets Webparts, the HTML Form Webpart, the Content Editor, Script Editor, Silverlight Webpart Media and Content Webparts, the Refinement, Search Box, Search Navigation, Search Results Search Webparts, the Catalog-Item Reuse Search-Driven Content Webparts and the Contact Details, Note Board, Organization Browser, Site Feed, Tag Cloud, User Tasks Social Collaboration Webparts.

References and Credits

None at this time…

Credits & many thanks to

Everyone!   SP2013logo _________________________________________________________ Enjoy!


Twitter | Technet Profile | LinkedIn

Office 365 – DTD is prohibited in this document issue




 Office365logo       SP2013logo

Got trouble Connection PowerShell to SharePoint online? This could be the resolution to your troubles.
I had this myself, or we had it in our Company tenant. This is what the issue was and this is how I fixed it:

When trying to connect to PowerShell for SharePoint Online, using the Connect-SPOService command, we got a error that did not tell us anything.

PS dtd error 1

The error is:
Connect-SPOService : For security reasons DTD is prohibited in this document. To enable DTD processing set DtdProcessing property on XmlReaderSettings to Parse and pass the settings into XmlReader.Create method.

Well, its almost a joke right…
When searching the web for information on this particular, I struck zero…all I could find related to the ISP and the default search provider something. I quickly dismissed them as unrelated.
Then after some time had passed, I found a similar issue, this seemed related and it was a connectivity issue same as mine (If I still had the link I would give credit to where credit is due). This fellow had resolved the issue by adding a missing DNS record.
This made me think, since our tenant has existed since way Before Office 365 existed (BPOS) perheps we were also missing some of the required DNS records?
I checked with my collegues, and apparently we were missing the record as well.

So, if you ever see or get the ‘DTD prohibited’ issue, remember to check the DNS for the following record:

Alias: MSOID
Info: Used by Office 365 to direct authentication to the correct identity platform More Information

After I added this to DNS, Connect-SPOService works just fine!



Microsoft’s official explaination on the DNS record:
What’s the purpose of the additional Office 365 CNAME record?

When you run a client application that works with Office 365 such as Lync, Outlook, Windows PowerShell or Microsoft Azure Active Directory Sync tool, your credentials must be authenticated. Office 365 uses a CNAME record to point to the correct authentication endpoint for your location, which ensures rapid authentication response times.If this CNAME record is missing for your domain, these applications will use a default authentication endpoint in the United States, which means authentication might be slower. If this CNAME record isn’t configured properly, for example, if you have a typo in the Points to address, these applications won’t be able to authenticate.

If Office 365 manages your domain’s DNS records,, Office 365 sets up this CNAME record for you.

If you are managing DNS records for your domain at your DNS host, to create this record, you create this record yourself by following the instructions for your DNS host.


References and Credits
Nope, not this time…Credits & many thanks to To all of you.




Twitter | Technet Profile | LinkedIn