Mark Minasi's Windows Networking Tech Page
Issue #104 February 2013

Document copyright 2013 Mark Minasi; please see below for info on subscribing, unsubscribing or copying portions of this text.

What's Inside

  • News
    • Learn with My Seminars, Audio Recordings and More!
  • Tech Section
    • Changing How Often Office 365 Makes You Change Your Password
  • Conferences
  • To Subscribe, Unsubscribe, Read Old Newsletters or Change Your Email Address


Hi all —

Man, it's been a busy few months -- nonstop travel and two new one-day courses. (One's a PowerShell course, the other is a Windows 8 support class -- but I'll cover that in an upcoming newsletter.) Meanwhile, I've had this issue with Office 365 needing me to change my passwords seemingly every other week, but I got that fixed. I want to tell you about it but first, a word from our sponsor...

Changing How Often Office 365 Makes You Change Your Password

I've gotten to the point where I haven't the time to run my own mail server.  (Arrgh.)  So last year I surrendered and got an Office 365 domain, and a small number of accounts.  And you know, it hasn't been all that bad.

Except for that password-changing thing.  (Arrgh, again.)

So did some looking, and found -- as some of you no doubt already knew -- that O365 lets you control your password policies, kind of.  (You get to control how many days between changes you require.  No control of length, complexity or whatever.  Maybe that'll change with the soon-to-come upgrade.)

So in case this helps anyone, here's how to do it th GUI way and, better, the PowerShell way.

Changing Office 365 Password Policies With the GUI

  • Log onto O365 at with your administrator account
  • On the top line you'll see Home, Outlook, Team Site and Admin.  Click the "Admin" link.  (It's probably already in the foreground.)
  • Below that, the bulk of the web page you'll see should have a few headings like "Admin shortcuts," Outlook, Lync, Team sites and documents, and so on.  Under Admin shortcuts you'll see a link "Reset user passwords;" click that.
  • In the "Users" page, you'll see "Active" and "Deleted" in large type and, below that, three lines including
  • Change the password expiration policy for your user:  Change now
  • Click on the "Change now" link.
  • A box will pop up labeled "Password expiration policy," which will let you punch in the number of days that your users can keep a password before it expires.  There's just one number for the entire domain, and unfortunately no other items like complex or simple, how many passwords to remember, length or the like.  The biggest number you can enter is "730" -- and that's not two years, "730" means "password never expires" in O365-land -- and then click "Save."

Changing Office 365 Password Policies With PowerShell

Or... there's the PowerShell way.

A bit over a year ago, Microsoft released a few PowerShell cmdlets that you can use to control your Office 365 domain.  You can find them at or, if they've moved them around, just use your favorite search engine to look search on the phrase "Use Windows PowerShell to manage Office 365" and be sure to surround it with quotes.  

Click the link "Install the Office 365 cmdlets," and you'll see this page:

You'll need to do two installs -- the "Online Services Sign-in Assistant" and then the "Microsoft Online Services Module for Windows PowerShell," and you can see that you'll have to choose the 32-bit or 64-bit edition.  (Do it in that order -- the PowerShell tools want to see the Assistant installed before they'll install.  Also, notice that it wants by default to put some pointless icon on your Desktop; I'd uncheck the box and tell it to skip the icon.)

Once you've got the thing installed, you have two new modules on your system, "MSOnline" and "MSOnlineExtended."  (Yes, the page only mentions MSOnline, but you do indeed get two modules, as you can see by typing get-module listavailable.)  You can see the new cmdlets bestowed by these modules by typing

get-command | where {$_.modulename -like "mson*"}

Or in two separate and shorter commands:

gcm -module msonline


gcm -module msonlineextended

None of those cmdlets are going to work, however, until you log onto your O365 domain by typing


That'll pop up a logon box.  Fill in your credentials and you'll get a PowerShell prompt.  (Remember, for many PowerShell cmdlets, no news is good news.)  What might you run?  Well, get-anything tends to be safe, so here's a few:

PS C:\Windows\system32> gcm get-* -module msonline
CommandType Name ModuleName
----------- ---- ----------
Cmdlet Get-MsolAccountSku MSOnline
Cmdlet Get-MsolCompanyInformation MSOnline
Cmdlet Get-MsolContact MSOnline
Cmdlet Get-MsolDomain MSOnline
Cmdlet Get-MsolDomainFederationSettings MSOnline
Cmdlet Get-MsolDomainVerificationDns MSOnline
Cmdlet Get-MsolFederationProperty MSOnline
Cmdlet Get-MsolGroup MSOnline
Cmdlet Get-MsolGroupMember MSOnline
Cmdlet Get-MsolPartnerContract MSOnline
Cmdlet Get-MsolPartnerInformation MSOnline
Cmdlet Get-MsolPasswordPolicy MSOnline
Cmdlet Get-MsolRole MSOnline
Cmdlet Get-MsolRoleMember MSOnline
Cmdlet Get-MsolSubscription MSOnline
Cmdlet Get-MsolUser MSOnline
Cmdlet Get-MsolUserRole MSOnline

Now you can run cmdlets against your O365, like this one, which shows that I went for the $6/person/month O365:

PS C:\Windows\system32> Get-MsolAccountSku|ft -auto
AccountSkuId ActiveUnits WarningUnits ConsumedUnits
------------ ----------- ------------ -------------
markminasi:LITEPACK 5 0 5

("Lite Pack," indeed! If those clowns had done a better job of explaining why I wanted to spend the extra two bucks per person, they might have gotten their money, y'know?) As is the case with so many PowerShell cmdlets, Get-MsolAccountSku actually knows a bit more than it's telling, but you can get it to cough up more info by adding "| fl" as in

get-msolaccountsku | fl

The difference is small in this case, but gets larger when you ask for what it knows about your account, as in

get-msoluser -UserPrincipalName | fl

And I'll spare you the output, but try that command (using an O365 user name for which you have authority) without the "| fl" and you'll see there's a lot less information.

Let's return to the question at hand, though -- how to I keep my users from having to change their passwords every time they turn around? That's get-msolpasswordpolicy. It needs the parameter "-domain" followed by the O365 domainname. Run that and you'll see something like

PS C:\Windows\system32> Get-MsolPasswordPolicy -domain | fl
ExtensionData : System.Runtime.Serialization.ExtensionDataObject
NotificationDays : 14
ValidityPeriod : 729

But how to extend your password "validity period" from the paltry few weeks you get by default to something longer like, say, six months? Well, whatever get-something displays in PowerShell, there's usually a set-something to change that, and there's no exception here. Set-msolPasswordPolicy looks like

set-msolpasswordpolicy -domain domainname -validityperiod daysbetweenpasswordchanges -notificationdays warningdays

For example, to set my domain's maximum password age to 180 days and to start annoying warning the user of the need for a change 30 days ahead of time, I'd type

set-msolpasswordpolicy -domain -validityperiod 180 -notificationdays 30

This cmdlet has an odd little quirk about it. The PowerShell Help says that the -domain, -validityperiod and -notificationdays parameters are all required, but if you leave off -notificationdays -- if you're setting your maximum password age to "forever," why notify? -- then you do not get a "missing parameter" error, just a less-than-helpful "Unknown error occurred."

Oh, and one more thought... I sure hope that this information becomes massively out of date and unhelpful when the O365 update happens.<wink>

To Subscribe, Read Old Newsletters, Send Me a Comment or Change Your Email Address

To subscribe: (which just means I'll send you about a three-tweet-sized message in plain text via email including a link to my latest newsletter), please visit

To change e-mail or other info, drop me a line (haven't figured out a secure method yet).

To read old newsletters: visit and, if you like 'em, please consider subscribing.

To send me a comment:  I'm at

All contents copyright 2013 Mark Minasi.  I encourage you to quote this material, so long as you include this entire document. Thanks very much for reading, and see you next time.