Master & Cmd-R

Microsoft Flow: Tweet New Posts from WordPress

While looking for a new plugin to post to Twitter whenever I publish a new blog post, I decided to give Microsoft Flow a try – here’s what the process looks like:

Log in to Flow (or create a free account) – you can search the gallery of templates if you like,


or just click on my flows and then create from blank to get started.


Start by adding a trigger – here we just search for WordPress, but you can add a number and variety of triggers:


Next, sign in to your WordPress account:


Once signed in, click Approve to allow Power Apps to connect to your WordPress sites – you can see from the screenshot below that if you have multiple sites, this will allow Power Apps to access them all.


Next, click on New step, and add a new action:


Now we’re going to post to Twitter, so search for Twitter, then select the Twitter – Post a tweet action.


Next, sign in to Twitter to create a new connection:


Then authorize Power Apps to post on your behalf:


I chose the options to post the Title and the URL of the post along with the New Post: text, but you can choose from a number of options for adding dynamic content – another cool idea would be to post your Like or Comment count once a post has received a certain number of either metric.


Save your flow, and you’re good to go!


 


It looks like there’s quite a few options available for creating your own custom flows and apps Microsoft Flow – I look forward to seeing what other cool things I can come up with! 😉

Happy New Year, one and all!!

 

** Edit: Looks like you can’t use URL in the Media section – only actual video or image files, so I changed the Tweet text to “New Post: Title – URL

MVP 2017!

I’m so excited to open my email on New Year’s Day to find this email from Microsoft:


It almost sounds cliché to say that I’m humbled and honored, but it is honestly such an amazing feeling to be invited to be a part of this awesome community of passionate, incredibly smart people. I love being able to help people, and whenever I get a comment from someone who has found one of my blog posts helpful, it makes me want to keep going and do more – I’ve been on the receiving end of that generous giving from others in the MVP and tech community, and it’s great being able to give back as well.

Here’s to an awesome 2017 in the cloud!

Fixed: PXE Boot Process loops 4 times

I ran into this issue on a recent Windows 10 deployment for a client – when the machine attempted to PXE boot from the WDS / MDT server, it would go through four iterations of the PXE boot cycle before finally getting the correct boot image from the server. Worse, if you have WDS configured to require F12 to continue, you have to press F12 each time, or it will time out and fail.


I tried a number of fixes to see if I could resolve the issue, including:

  • Setting default boot images – didn’t work
  • Removing the F12 requirement – didn’t work
  • Removed option 67 from the DHCP scope – didn’t work
  • Removed option 66 just for good measure – didn’t work
  • Tried changing option 67 to the boot wim, wdsnbp.com, pxeboot.n12 – didn’t work

NB: In case you’re wondering what these boot options actually are, here’s some of the settings you might be seeing: https://support.microsoft.com/en-us/kb/259670

After much searching, and not much luck, I stumbled across the following forum post, and gave it a shot:

On the network settings of the WDS server, Disable NetBIOS over TCP/IP:


Problem solved!


Azure Point 2 Site VPN: DNS config is wrong

Just ran into this issue when I created a P2S VPN on my Azure Virtual Network – I downloaded the client and connected ok, but I realized I could only connect to my servers via IP, not by FQDN.

Checking my local IP settings, I realized that the DNS Server on my VPN connection was set to a public DNS server and not my Domain Controller / DNS server in Azure.


This wasn’t completely unexpected, because when I created the vnet I used Google DNS, and then I went back to the settings and changed it later once I had my DC set up.


It turns out that when you download the P2S VPN client from the Azure portal, it’s not really a client in the traditional sense (like the Cisco AnyConnect client) – it’s actually a number of config files that get installed to %appdata%\Microsoft\Network\Connections\Cm\connection-name\.

You can try editing the phonebook file as I’ve seen suggested around the web, but I don’t really like that solution – in order for this to work, you need to dial through the phonebook (pbk) file, and not just through the built in Windows VPN connection.


The answer, thankfully, is simple – just remove that VPN client and re-download the P2S VPN client from the Azure portal. Install it on your PC as before, and you’re good to go:


All better now!


OneDrive: Deleted user retention

As part of ongoing user management, this question comes up from time to time:

What happens to a user’s OneDrive library when their account is deleted?

The short answer is that user data is retained for 60 days after their account is deleted, and then irretrievable after that. During that time, the data can be retrieved by the user’s manager, or by a secondary site collection admin. It’s important to note that the OneDrive cleanup process ONLY happens on user account deletion, not disabling the account or removing their license(s).

Here’s the process:

  1. By default, when a user account is deleted ownership of their OneDrive library is assigned to their manager. For this to work, however, several things have to be in place beforehand.

     a. The manager field needs to be populated in AD
     b. Access Delegation needs to be enabled in SharePoint Online, as indicated in the following screenshot. Note that this is a global setting that will be applied for all users, and is recommended as a best practice.



     c. A secondary owner or site collection admin can be assigned on this page as well, allowing for further control or access to be provided for a deleted user.
  2. Once a user profile has been deleted, a timer job runs which marks the account for deletion in AD, and flags the OneDrive library for deletion in 30 days. If the Manager field is populated, they will receive a notification at this point that the site will be deleted in 30 days, so they can go and retrieve any data and save it elsewhere. If the Manager field isn’t populated, the notification will go to the Secondary Owner, or Secondary Site Collection Administrator. If none of these 3 fields is filled out, the workflow will continue below, but no email notifications will be sent.
  3. After 23 days, the Manager / Secondary Owner / Secondary Site Collection Admin will receive a final notification that the library will be deleted in 7 days.
  4. 30 days after the user has been deleted from AD, their OneDrive library is deleted, and moved to the Site Collection Recycle Bin.
  5. After another 30 days (60 days from user deletion in AD), the OneDrive library is cleared from the Site Collection Recycle Bin.

More info: https://support.microsoft.com/en-us/kb/3042522

What about if the account is disabled in AD?

 If a user has been disabled in AD (but not deleted), the account status in Office 365 changes to Blocked, and the user’s OneDrive site collection is not accessible until an administrator takes ownership of it.

In the case of my test account, the Manager property wasn’t set, neither was the secondary site collection owner/administrator – if either of those properties were in place, the library would have been available to those people. Since those attributes weren’t set, it required taking ownership manually as a SharePoint admin, at which point I could access the library.

Bottom line: the user’s OneDrive library deletion cycle starts when the account is deleted, not when it is disabled. This is a fairly large distinction, as I’ve seen many environments where user accounts are disabled, and sometimes left in that state for years without clearing them out. However, you need to be careful with this practice – if you disable the user account and move it into a Disabled Users OU (for instance) that is excluded in the Azure AD Sync, this WILL delete the user account in Azure AD and trigger the start of the deletion process.


Add-AzureAccount fails – Your browser is currently set to block cookies

I recently ran into an issue while running Server 2016 attempting to connect to my Azure account through PowerShell – after installing the Azure PowerShell Modules and running Add-AzureAccount, an authentication window opens, allowing you to connect to your Azure account. However, instead of seeing the logon window, I would only get the following error:


“Your browser is currently set to block cookies. You need to allow cookies to use this service.”

Figuring that Edge was blocking cookies due to the default security configuration in Server 2016, I attempted to open Edge so that I could unblock those sites and be able to log in to my Azure account and continue my server configuration. Seems like that’s a dead end as well!


I hadn’t run into this before, but apparently it’s a known issue – I decided to just create another admin account rather than going down the route of editing my registry settings, as I didn’t really want to start poking holes in my brand new server. It might be completely safe, but I figured I’d just leave it as is – I didn’t really see much use for Edge on my default admin account anyway.

However, after creating a new admin account, logging in, and launching Edge, I found that cookies were indeed already enabled, and I was still having the exact same error connecting to my Azure account in PowerShell. It turns out that the culprit is Internet Explorer, and not Edge at all! If you open Internet Explorer (Start – Run – iexplore.exe) and attempt to log in to https://portal.azure.com or https://login.microsoftonline.com you’ll receive a very similar error:


The answer to this strange little conundrum is just to go in and add the following two sites to your trusted sites in Internet Explorer:


Once this was done, I was able to connect to my Azure account using both Microsoft Account (@outlook.com), and my Office 365 account (@microsoftonline.com). Knowing this, I went back to my built in administrator account and added both those sites to my trusted sites in IE, and all was well with the world again.

Long story short… just add the Microsoft authentication sites above to your Trusted Sites in IE 11 (even on your built in admin account), and you’ll be able to connect to your Azure account properly.

Hope this helps save you some time searching for an answer to this weird problem – good luck!

Block Yammer Access in Office 365

Since April 2016, Microsoft deprecated Yammer Single Sign On capabilities – up until this point, if you wanted to block users from accessing Yammer, you needed to configure a relying party trust in ADFS / SSO, and block all users who are not members of a specific group. While this feature worked well (in my experience), the updated process that Microsoft implemented is way better, and much easier to implement.

Now, instead of configuring Single Sign On, you only need to do three simple steps to prevent users from accessing Yammer:

  1. Enforce Office 365 Identity in Yammer; (more info)
  2. Block Office 365 users without Yammer licenses; and,
  3. Remove the user’s Yammer license in Office 365. (more info)

The first two of these steps takes less than 5 minutes to complete, but it has an immediate and potentially large impact, so you need to make sure that these changes are planned and the impact accounted for before you do this. If you’re users are not using Yammer yet, all the better – click away!

Enabling Office 365 Identities in Yammer:

Log into your Yammer network, and select Network Admin – Security Settings. You need to be a network admin in order to even see these settings, and if you’re a Global Admin in Office 365, you’ll also be a Network Admin in Yammer, so you should be good to go.

On the Security Settings page, you’ll see a section for Enforcing Office 365 Identity in Yammer. If you’ve never selected either of these fields before, here’s what to expect:

  1. When you enforce Office 365 Identities in Yammer, anyone who logged into Yammer with a Yammer account (or created one on their own), will no longer be able to log into your network in Yammer. This is a great way to start consolidating identities, as Yammer used to allow a combination of both Yammer and Office 365 accounts, and a user could have either, or both – quite messy!

Once you select the option to Enforce Office 365 Identities, you’ll be able to immediately log all users out, and force them to sign back in, this time with their Office 365 accounts. This is useful if you want to implement an immediate change, but keep in mind that users will be logged out immediately, so communicate this change, or you could have some unhappy users on your hands.

  1. Once you are enforcing Office 365 Identities, you can go ahead and click the option to block Office 365 users without Yammer licenses. Once again, you’ll have the option to log all users out of Yammer, so plan your changes and communication accordingly. Note that you can enable both of these options at the same time – you don’t need to wait in between selecting the different options.


If you want to go for a softer approach, leave the option unchecked to log out all current users, and these users will be able to continue to use Yammer until the next time they try to log in, at which point, they will require a valid Office 365 account, and a Yammer license assigned to their account.


You still need to click Save before these setting take effect, so you have one last chance to back out if you’re not sure if you’re ready to kick everyone out of Yammer or not!


  1. Now that you’ve got your identities consolidated to Office 365, and are blocking Office 365 users without Yammer licenses, simply log back in to Office 365, deselect the Yammer Enterprise option, and click Save.


Now when a user without a Yammer license attempts to connect to Yammer by logging in at http://yammer.com, this is what they’ll see:


Note that if you go about this from the opposite direction, removing a user’s license won’t prevent them from accessing Yammer if you haven’t done the first two options. Once you’ve got steps 1 and 2 completed, they will be immediately blocked from logging into Yammer, and will see the error message above.

Remove Yammer licenses globally through PowerShell:

Microsoft provides a script for removing a single user’s Yammer license through PowerShell, but here’s how you would achieve this if you wanted to disable Yammer for all users:

# Connect to the MSOL Service
$credential = Get-Credential
Connect-MsolService -Credential $credential
 
# Gather all licensed users into a variable
$yammerUsers = Get-MsolUser -All | Where {$_.IsLicensed -eq $true}
 
foreach ($y in $yammerUsers){
$LicenseDetails = (Get-MsolUser -UserPrincipalName $Y.UserPrincipalName).Licenses
 
foreach ($License in $LicenseDetails) {
 
 $DisabledOptions = @()
 $License.ServiceStatus | ForEach {
 
 If ($_.ProvisioningStatus -eq "Disabled" -or `
 $_.ServicePlan.ServiceName -like "*YAMMER*") {
 $DisabledOptions += "$($_.ServicePlan.ServiceName)" 
 
    } 
 
 }
 
 $LicenseOptions = New-MsolLicenseOptions -AccountSkuId $License.AccountSkuId -DisabledPlans $DisabledOptions
 Set-MsolUserLicense -UserPrincipalName $y.UserPrincipalName -LicenseOptions $LicenseOptions
 
    }
 } 

Please note that this script will remove all Yammer licenses globally, and no-one will be able to log into Yammer until you have gone back and re-enabled their Yammer Enterprise license. The good news is that this change doesn’t delete anything in Yammer, and once a license has been reassigned in Office 365, users can log back in as normal. As always, scripts are provided without warranty or guarantee – be smart and test scripts before releasing them in the wild and making global changes to your tenant!


Skype for Business: Hide Stage

This drove me crazy for a while, because I couldn’t find the option to hide the stage in a Skype for Business conversation once I no longer wanted to see what someone was presenting on their screen – might not happen very often, but it happened enough to want to hunt it down, and it’s not as intuitive as I’d think it would be. Honestly, I expected the option to be a bit more straightforward, like maybe at the top of the screen right beside Request Control? I’d even settle for it being behind the ellipse (…) on the bottom right, but no…

To hide the stage, click the sharing button, then Hide Stage:

Hide Skype for Business Presentation Stage

Hide Skype for Business Presentation Stage

Simple, right? Just as simple as clicking File – Open – Import in Outlook 2010 to actually export a file!



Sigh… hope this helps someone else who’s been wondering where that dang “hide stage” button is!

Use PowerShell to Update Room Calendar Working Hours

I recently had a request to update a bunch of Meeting Room calendars whose Working Hours were set to the wrong time zone, which was causing issues when users tried to view or book appointments in those rooms. Now, I know I could do this by logging into each room manually, but where’s the fun in that? 😉

To update all of the rooms at once, I first needed to figure out how to get the mailboxes I needed, and then get their mailbox calendar configuration. You can do this by using Get-Mailbox with some filters to find the mailboxes with calendars that you want to change – in this case, I knew that they were all Room Mailboxes, and they all began with “HKG-“. You can structure your queries to filter by whatever you want, really – just do a Get-Mailbox username | FL to find out the name of the attributes that you can use in your query. In this case, the attributes I needed were called DisplayName and RecipientTypeDetails – once I had the mailboxes, the next step is to pipe it out to a Get-MailboxCalenadarConfiguration, so I could see what they were set to.

This is what the script looks like:

Get-Mailbox -ResultSize Unlimited | Where {$_.DisplayName -match “HKG-” -and $_.RecipientTypeDetails -match “RoomMailbox”} | Get-MailboxCalendarConfiguration | FT -AutoSize

It should go without saying, but make sure you’re connected to Exchange Online before you run this command!

And this was the result:


You can see from the screenshot above that all but one of the rooms was on Central Standard Time, and only one of them was in the correct time zone; to fix it, I use the first part of my script (the Get-Mailbox portion), and then pipe the results out to a Set-MailboxCalendarConfiguration, along with the attributes I want to change. For this scenario, it was WorkingHoursTimeZone, WorkingHoursStartTime, and WorkingHoursEndTime, like so:

Get-Mailbox -ResultSize Unlimited | Where {$_.DisplayName -match “HKG-” -and $_.RecipientTypeDetails -match “RoomMailbox”} | Set-MailboxCalendarConfiguration -WorkingHoursTimeZone “China Standard Time” -WorkingHoursStartTime 09:00:00 -WorkingHoursEndTime 18:00:00

Much better now!


If you only need to do this for a single user, use the following command in PowerShell:

Set-MailboxCalendarConfiguration adm-jdahl -WorkingHoursTimeZone “Pacific Standard Time” -WorkingHoursStartTime 09:00:00 -WorkingHoursEndTime 18:00:00

And then to view the results:

Get-MailboxCalendarConfiguration adm-jdahl | ft -AutoSize

Hope this helps someone learn a new way to do something cool in PowerShell!

Inbox rules: Inconsistent Forwarding

The issue: Inconsistent Forwarding Rules

I ran into an interesting issue on a recent migration: my client had a rather complicated forwarding scenario set up to manage a number of email subscriptions. Various folks around the (global) organization had signed up for these subscriptions, and they wanted to be able to distribute them throughout the company.

In order to facilitate this requirement, each subscription user had inbox rules set up to forward these subscriptions to a single mailbox, which then had around 50 inbox rules that were taking these emails and forwarding them on to a number of distribution groups, and then filing the email away in a folder – complicated, right?

First Rule: External Subscription to User:


Second Rule: Forward Subscription to Group:


Interestingly enough, this scenario worked in their old hosted environment, but once these mailboxes were migrated to Office 365 these rules started failing in a strange way: the rule would fire and move the message to the appropriate folder, but it wouldn’t actually forward the message on to the distribution group!

We tried recreating the rules, changing the wording of the rules, redirection vs. forwarding, etc. – nothing worked. Even weirder, if you tried to trigger the rule manually by sending an email from the source mailbox which met the rule criteria, the rule would trigger properly, making us think we actually had it solved this time. However, the next time the rule was activated automatically it would go back to the old behavior of filing but not forwarding.

So. Frustrating.

 

The Answer: “By Design”

Eventually I found the answer on the following forum post: Basically, as long as Exchange detects that the email was forwarded or redirected via a rule (mail headers include the field X-MS-Exchange-Inbox-Rules-Loop), it will not forward it a second time. This is by design in order to prevent unlimited loop forwarding.

This is also why we could trigger the rule manually by sending an email from the source mailbox – since the email was not forwarded it wouldn’t be caught by this behavior.

 

The Fix: Easier than you’d think

Thankfully, once we realized why this was happening, it was easy to resolve – simply remove the first forwarding rule (eliminating the loop potential), and instead replace it with a transport rule in Exchange Online.

For this rule, you can match the settings of the original inbox rule: If the sender is someone, do something. Depending on your requirements, you can choose to have it redirect the message, or simply Bcc the message to another user. Remember that if you choose redirection, the email will no longer go to the original user, so you might want to choose Bcc instead.


If you want to filter it better than this (the rule above might catch more emails than you want), simply click more options at the bottom of the rule window:


Once you have more options enabled, you can add as much details as you need to make sure you’re just catching the email you want, and not casting too wide a net:


Once you save your rule and activate it, make sure you disable or delete the original inbox rule so that you’re not generating duplicate emails, and then sit back and enjoy the magic!