FIRST – I am stealing code here and re-sharing (with very little modification). All credit goes the fine gentleman that wrote these two articles, I would urge you to read them:

Bulk Add IP Access Restrictions to Azure App Service Using AZ Powershell

Bulk Add Cloudflares IPs to Azure App Service Access Restrictions Using AZ Powershell

I made a few minor modifications the provided code. First, I like to just run a lot of my Azure Powershell stuff from an ISE session and don’t like encapsulating everything in new commands. Partly because I am not all that familiar with working that way even though it is probably a MUCH better way of doing things.

Before we get to the code though, what is this for exactly?

If you use cloudflare as a protection and CDN layer for a website it works by acting as a reverse proxy for your site. I.E. client connects to your site by a cloudflare hosted DNS record… instead of connecting directly to your server, their connection terminates at Cloudflare, they do things, then the pass the connection along to your actual service. ‘Nuff said, google if you need more info.

In the case of an Azure Web App (or any other web server I supposed), the app is hosted/available on some public IP and/or azure domain name that azure provides when you create the app…

What this means is that someone can easily bypass your cloudflare layer (and the associated performance enhancements and protections like web application firewalls) if they know your source systems IP address and in the case of azure, your azure provided domain name for your app.

So what that means is that you need to setup an ACL (Access Control List) on your source system to say “Allow traffic from all Cloudflare IP ranges and block everyone else”.

Cloudflare has like 20 IP ranges… And setting up that ACL by hand on a web app in Azure is arduous at best. But that is why we have scripting… to make things that are generally a pain in the rear… NOT a pain in the rear. (more…)

This will (hopefully) be brief…

Here is the Scenario:

  • You have deployed Office365
  • You have an on-prem Domain Controller (hopefully more than one!)
  • You are using Azure AD Connect 1.1 or greater, (which is installed on one of your domain controllers)
  • You create or manage user accounts using your on-prem domain controllers
  • Whenever you create a new user or make a change in AD you have to wait around (up to 30 minutes) for Office365 to reflect the change

In previous version of AAD Connect there was a Windows Scheduled task that would periodically sync AD data to Office365.

In later/latest versions of the tool there is now a scheduling engine that is part of the tool which is set to do a “delta” sync (only updates/changes) every 30 minutes.

When you are working though you might not want to wait around 30 minutes.
(more…)

I am going to get right to it today. I really don’t like Microsoft Exchange. I think it is a bloated, convoluted, over-priced product. Welcome to being a Microsoft admin :).

I was recently tasked with doing a bit of investigative work on an Exchange server and determining what all was using the box for mail services. To that end, I needed to answer two questions…

What mailboxes are currently in use?
What is currently using this machine as an SMTP server to send mail out?

Below I am going to provide the powershell commands I had to figure out which helped me answer those questions. (more…)

I have been working on email stuff on and off for the last… forever.

One of the very handy and easy to use tools to have in one’s pocket for testing email functionality with a particular SMTP server is the ability to quickly send email through a selected server from the command line. Just like using telnet to test ports makes day-to-day IT life easier vs. having to grab and install some extra tool, so also does the ability to shoot emails off from a CLI.
(more…)

This is a quick snippet for all of you working with RDS in Server 2012+… and bemoaning the fact that Microsoft took something relatively simple and made it horribly convoluted…

In Powershell you can manually set a Session Host Server to use a specific licensing server and mode. To do so you run the following on the session host server.

$obj = gwmi -namespace "Root/CIMV2/TerminalServices" Win32_TerminalServiceSetting
$obj.SetSpecifiedLicenseServerList("servername.contoso.local")

$obj = gwmi -namespace "Root/CIMV2/TerminalServices" Win32_TerminalServiceSetting
$obj.ChangeMode(VALUE)

First two commands specify the licensing server you want. Hence change servername.contoso.local to your environment. That’s only the first half though. You then need to set the licensing mode and that is what the second two commands do. Where it says VALUE you can enter in either a “2” or a “4” depending on the type of licensing you have.

2 = Per Device
4 = Per User

Hope this saves someone else some headache… I think the MS approved way to do this is probably to use group policy but this is a quick and dirty method if you just need to get a machine working quickly.