Tuesday, October 31, 2017

When good Flows go rogue

At about 2.15am local time this morning, two Microsoft Flows in my Office 365 tenant went rogue and started blasting select email addresses with continual emails.

The two Flows in question I used to handle registrations for my regular monthly webinars. You can read more about how I created these here:

Using Microsoft Flow for event confirmations

Basically, they are triggered by a submission from Typeform. They then send the registrant a confirmation email as well as writing the details to a SharePoint list. These Flows are linear and incorporate no looping. These Flows had run successfully for over 12 months and had not been edited, changed or even viewed in a few weeks.

However, at approximately 2.15am local time, both of these Flows started to execute repeatedly sending hundreds of emails to a select group of people who had previously registered for the webinars.


The above shows a very small sample of the the sent items from the mailbox in question.

The mailbox sending out the emails from the rogue Flows was not my production mailbox so when I checked my production inbox just before 6 am local time when I awoke, I was quickly made aware of the issue from various people.

I immediately logged into the tenant with the rogue Flows and disabled the Flows but emails continued to be sent. I then went in and deleted the Flows but email continued to be sent. I therefore went in and created an Exchange transport rule to prevent that mailbox from sending anything further.

At that point the emails stopped being sent. In hindsight, that could have been from exhaustion of emails queued to be sent upon disabling the Flows. Whatever the reason, outbound emails had apparently stopped.

I immediately then logged a support request with Microsoft to confirm that the rogue Flows where not still running in the background, even though I had deleted them.

My request was escalated to the SharePoint Team who look after Flow. All the details of my situation were recorded and verified via a screen sharing session.

With the Exchange transport rule still in place I looked at the Flow Admin and found:


I then downloaded the CSV file to get more details and found:


The two rogue Flows had each run almost 5,000 times. Clearly an issue.

At this stage Microsoft is still investigating the issue behind the scenes and I have removed the Exchange transport rule and confirmed emails are not being sent. Thus, it appears the rogue Flows have ceased.

What is interesting here is that the Flows that went rogue were only designed to run once someone completed the online Typeform. However, overnight they decided to run over and over again obviously caught in some sort of loop.

My guess as to the cause is that the Typeform connector used with Microsoft Flow received some type of update causing it to replay previous registrations over and over. The strange part is the fact that it kept repeating even though it was never designed to loop.

I am sorry to those people who received over 600 emails from me due to this issue and if it keeps happening or reoccurs please contact me asap and let me know.

With both Flows now deleted I am going to have to rebuild them but the question is how (can?) I prevent something like this happening again?

My current thinking is that I move the registrations to their own dedicated email box that I can, in the worst situation, completely delete if needed. I also need to work out some sort of rule that prevents constant email being sent if they exceed a threshold (say 10 emails in 10 seconds) and take appropriate action.

I’ll have to have a think about how (or if) I can do this and how I go about creating and monitoring any new Flows I create. I welcome any suggestions people might have on how I can prevent a recurrence.

A painful example of what happens when automation breaks.

Saturday, October 28, 2017

Need to Know podcast–Episode 168

In this episode I talk with Benjamin Elias from Ideocial about on of my favourite Office 365 service – Yammer. We follow up on some of the announcements from the recent Microsoft Ignite and how they will impact the product going forward. Of course, there is also news from Marc and myself on Office 365 and Azure to keep you up to date.

Take a listen and let us know what you think -feedback@needtoknow.cloud

You can listen directly to this episode at:


The podcast is also available on Stitcher at:


Don’t forget to give the show a rating as well as send us any feedback or suggestions you may have for the show.








Azure news from Marc

Office 365 and Linkedin

SharePoint and OneDrive idle timeout

Tuesday, October 24, 2017

Viewing all files with OneDrive on Demand


So you have installed the Windows 10 Fall Creators update with the new OneDrive on Demand feature. However, when you look at the files in your OneDrive you only see the one’s you were previously selectively syncing to your desktop. You don’t however see the full contents of the location you are syncing.

This is exactly the situation above, as you can see. I was previously doing a selective sync of only two folders from my OneDrive for Business to the desktop and this configuration has remained even though I have upgraded to the Windows 10 Fall Creators update. Here’s how you configure the your OneDrive sync client to see all your file no matter where they are.


Right mouse click on the OneDrive sync client in your taskbar (lower right corner near the clock). From the menu that appears select Settings.


Ensure you have the Account tab selected and then select option Choose folders for the location you are syncing from.


You see a list of all the files in your OneDrive for Business in the cloud as well as the location you are currently syncing, which have a check mark next to them.

Select the option at the top of the page, Make all files available.


You should now see a check mark next to every item as shown above.

Press the OK button to continue.


If you look at you synced location in your Windows Explorer you should now see every file listed as shown above. You should also see the ones that you added remain online (i.e. have a cloud icon next to them) and the information you previously select remains synced (i.e. the green check mark icon next to them). Thus, nothing additional will be synced to your desktop until you elect to do so. This now allows you to easily browse all the files in the synced source location.

Now you can easily and dynamically determine exactly which files you wish to have synced to your desktop will viewing all your files form that location.


Saturday, October 21, 2017

Deploying Office on the desktop with Microsoft 365

Microsoft 365 has handy functionality to help administrators roll out software to Windows 10 machines that are connected directly to Office 365. One of these tools is the ability to roll out Office desktop software automatically. Here’s how you make it happen.

You’ll firstly need to have licensed Microsoft 365 in your tenant. Next, you’ll need to have user Windows 10 machines directly joined to Office 365.


You’ll then need to login to the Office 365 portal as an administrator and navigate to the Admin center as shown above.


In the Admin center you’ll find a Device actions tile as shown above.

In that tile you’ll see an option Manage Office Deployment. Select that.


If this is the first time you have configured these deployment options you’ll need to select the + Add a group at the top of the page.


In this case, the All Users group will be selected but you could certainly target the deployment at specific groups of users.

Click the Select button at the bottom of the page to continue.


Next you want to install or uninstall Office for the selected group of users. Here, we’ll select Install Office as soon as possible.

Click Next to continue.


Check that the configuration is correct and select the Confirm button at the bottom of the page.


Select Close on the next dialog to continue.

If you now move to the user’s Windows 10 machines that is connected to Office 365 and launch the Task Manager you’ll be able to see how the process is executed on the desktop.


After a short time you’ll see an Office Deployment process kick off.


A short time later you’ll see a Microsoft Office Click-to-Run (SxS) process commence.


You may see multiple versions of this process running throughout.


Next, you’ll see the Microsoft Office Click-to-Run Integrator process kick off.


If you continue to monitor the running processes you’ll see installation processes for Office applications like OneDrive and Skype for Business run.


When the user runs an Office application for the first time they will prompted to Accept some terms and conditions then continue as shown above.


When the Office software launches it will automatically be logged in as the user so there is nothing more for the user to do.

The whole deployment process is completely silent and user receives no prompts until they run an Office application for the first time. If you want to see what’s happening you’ll need to look in the Windows Task Manager as shown here.

So, if you use Windows AutoPilot you can also deploy Windows 10 automatically to a desktop. Thus, with Microsoft 365, an administrator can automatically deploy both Windows 10 and Office software to an Office 365 user’s desktop without the need to even see the desktop or the user!

This is just the beginning of what you can do with Microsoft 365 so stay tuned for more articles on how using Microsoft 365 makes it easier for IT Administrators.

Friday, October 20, 2017

Introduction to Windows Autopilot

Microsoft has introduced a new technology called Windows Autopilot that allows you to easily deploy Windows 10 Professional and Enterprise machines with nothing more than just an Internet connection.

A good way to get a feel of how all this works in practice is to use a Virtual Machine (VM) as a test bed which is what I’ll show you here.

The first thing is that you are going to need to get some information about the machine so that it can be recognised by Windows Autopilot when it is provisioned. Normally, this information will be provided directly by the manufacturer of the PC, but here’s how it actually works behind the scenes.

For this test process we start by running up a new clean virtual machine with Windows Professional installed.

Once the machine is running (we don’t need to worry about connecting to Azure or a domain just yet), we need to run PowerShell as an administrator so we can extract the required information.


The first PowerShell command that needs to be run is:

wmic bios get serialnumber

record the number that it produces.


Next, run the PowerShell command:

Get-ItemPropertyValue "hklm:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\DefaultProductKey\" "ProductId"

once again, record the number that is output.


Finally, run these two commands:

$wmi = Get-WMIObject -Namespace root/cimv2/mdm/dmmap -Class MDM_DevDetail_Ext01 -Filter “InstanceID=’Ext’ AND ParentID=’./DevDetail'”

$wmi.DeviceHardwareData | Out-File “$($env:COMPUTERNAME).txt”

This will create a file containing machine identification information, basically a hash.


This file will be written to the location from which the PowerShell command was run. By default this will be c:\windows\system32.


If you open the text file created (which has the name of the machine) it should appear like that shown above.


With all the information safely recorded, you can now run SYSPREP to generalise the machine and reboot or blow away the version of Windows (but not the actual VM. That needs to be retained so it is correctly identified during the coming provisioning process).


You need to now create a .CSV file to upload so that the machine can be identified at boot and provisioned. You can see the format of the file above.

Basically, the machine configuration file has at least 2 lines. The first is a heading line:

Device, Serial Number, Windows Product ID, Hardware Hash

The second line are the results from your PowerShell commands above separated by commas.

Ensure that you save the file as .CSV not .TXT!

You’ll now need to upload this file to the web. Navigate to:


and login there with the Office 365 global administrator account for your tenant. This will typically be a tenant with Microsoft 365 licenses installed.


Once logged in the screen should appear like that shown above. Select the Manage option from the menu across the top of the page.


This should then take you to a screen like shown above. From the menu on the left hand side select Devices.


If this is the first device you’ve added to Windows Autopilot, you won’t see any existing devices.

Select the + Add devices menu option just under the Search devices box.


Navigate to the location of the .CSV file you created earlier that contains the information about your test VM. Select the file to upload it to the portal.


Since there are currently no deployment groups you’ll be asked to add a new one as shown above. Simply enter a group name and select Add.


The file should successfully upload to the portal and you’ll see a message telling you that it is being currently processed and you should refresh your screen to see the progress.


When the process is complete, you’ll get a happy green bar across the top and you’ll also see you machine listed below as shown above.


You’ll now need to create a profile for the deployment of Windows. Select the menu option AutoPilot deployment from the menu just above the list of devices as shown. From the menu that appears select Create new profile.


Give the new profile a name (here Test-Policy) and select any other desired settings.

Select the Create button when complete.


That will take you back to the list of devices. You’ll now need to apply the new profile you just created to the machine you have just added.

To do this, select the machine from the list.


Then select the option to Apply the appropriate policy.

Most of what we have just done will actually be done by the PC supplier down the track. They will basically get the details of each PC prior to shipment and upload that into the portal where you can then create and apply policies. We have stepped through the whole process here because we are using a virtual machine and to show you what actually happens.

The idea at this point is the new Windows 10 machine is shipped out to the end user. The only requirement the user needs to have is their Office 365 login details plus an Internet connection.


If we now re-provision the original machine it will boot to a point and ask the user to confirm their regional preference.

Make a select and press Yes.


They will then be prompted for a keyboard layout.

Make a selection and press Yes.


The use will also be prompted for any additional keyboard configuration. In most cases the user will select Skip here.

At this point the new machine will check to see whether it is connected to the Internet. If it detects a wifi network it will prompt the user to login. This means the machine can be provisioned ANYWHERE there is an internet connect (i.e.at home, at a coffee shop, etc). It doesn’t need to be connected to the corporate LAN.


The next prompt will ask the user to login with their Office 365 account. This is their Azure AD account which is the same as they use to login to the Office 365 portal.


The user will now be prompted for their password.


The machine will now add itself to the Office 365 Azure AD and apply any policies that have been configured. I’ll cover the deployment of custom policies and application deployment in another article.


After a few moments the user will be logged into the Windows 10 machine and will display the information from their Office 365 account as shown above.


You will also find that the machine has been joined to Azure AD as shown above.


If you dig into the user accounts on the machine you will find that there are no local accounts enabled as we elected back when we set up the initial AutoPilot profile in the portal.


Now, thanks to Windows Autopilot, we have quickly and easily deployed a new Windows 10 machine without the need for administrative intervention (such as joining to a domain). This machine is now directly connected to Azure AD and any Office 365 user can now login.

Although this process has been done using a virtual machine it can be done with any Windows 10 Pro or Enterprise machine. The main requirement is to get the machine information into the web portal so that it can be identified and provisioned at boot. Obtaining that information is as simple as a few PowerShell commands so you can try it for yourself to get a feel of how well it works.

For more information on Windows Autopilot visit - https://docs.microsoft.com/en-us/windows/deployment/windows-10-auto-pilot