Set passwords to never expire | Office 365

Whilst the majority of Office 365 users would have DirSync configured so users will be using their Active Directory user accounts & passwords, some businesses will be using the cloud user accounts, which have their passwords expire.

It's very simple to configure all cloud O365 accounts to have their passwords never expire, which will especially stop the inconvenience of having to update admin accounts etc.

To do this, you will need to log into Office 365 through PowerShell.  You will also need to do the second part of the attached blog by connecting to the MSOL service.

Once you've done that, use the following command:

Get-MSOLUser | Set-MSOLUser -PasswordNeverExpires $true

Office 365 Published Calendar | Publish Date Range | Extend Past 6 Months

I recently had a client who uses an Office 365 calendar to show up on a website of theirs.  This was to make a certain calendar publicly available to everyone.  They realised that the calendar on their WordPress website was only showing six months ahead of time, and didn't show anything further than that.

This can be changed to a maximum of 12 months ahead of time for viewing calendar items, which I think is sufficient for a publicly available calendar (published calendar).  In order to find out the current setting, you will need to do this through PowerShell with the following command:

Get-MailboxCalendarFolder -Identity <EmailAddress>:\calendar

The field you're looking for is PublishDateRangeTo.  In the screenshot above, it shows the already changed field.  By default, this is set to SixMonths.

This explains why your published calendar suddenly goes blank after exactly six months.  In order to change this, you will need to use the following command:

Set-MailboxCalendarFolder -Identity <EmailAddress>:\calendar -PublishDateRangeTo OneYear

Once you have done this, use the following command to double-check and make sure it's showing the correct setting now.

Get-MailboxCalendarFolder -Identity <EmailAddress>:\calendar

If you check your published calendar, you will see that it now shows 12 months worth of events.

Configure SMTP Relay from On-Prem to Office 365

The following steps will guide you through creating a SMTP relay on a server which will allow you to use the Scan to Email functionality on printers/copiers etc, relaying through Office 365.

This is probably the easiest way to get devices emailing out once you've migrated to Office 365.

1. Find a server that you're going to use as the SMTP Relay, go to Server Manager and then Add Roles and Features

2. From Server Manager, click on Tools, then IIS 6.
If you haven't installed this yet, please do so

3. Expand the serer name, right click on SMTP Virtual Server #1 and click on Properties

4. Click Access tab, then Relay.  Then select either specific IPs or select "All except the list below".

5. Click the Delivery tab, then click Outbound Security, tick Basic Authentication, then enter a username and password of an Office 365 mailbox.  This is used for authentication with your Office 365 tenant.

6. Make sure TLS Encryption has been ticked

7. Click Delivery, then Advanced, then enter smtp.office365.com as the Smart Host address.

That is all you need to do to get the SMTP Relay up and running.  To test this is rather easy as well, and it's highly recommended that you test it before configuring devices to send through this relay service.  

Test Relay Service

1. Create a new Notepad document with the following contents

FROM: scantoemail@domain.com (same as the mailbox you're authenticating with)

TO: adam@mydomain.com (email you're sending the test to)

SUBJECT: Test email

Save this as Email.txt.  Copy this .txt file to C:\inetpub\mailroot\Pickup.  It should immediately disappear as it's picked up and sent through the relay.  

If this arrives in your mailbox, then it's all up and running.  Just make sure that when you're configuring printers etc, the send 'from' address needs to be the same address that you're authenticating with on the SMTP Relay server.  If the emails don't match up, it will error out and won't send.  You can setup the devices to send anonymously as well, and the authentication is done on the SMTP Relay server side. 

Assign License via PowerShell | Office 365 | Script

Thanks to my colleague Gareth Harris for this script.

I have recently been running a few large-scale (1000+ mailboxes) and I've had to rely on scripts for assigning licenses and converting mailboxes to shared mailboxes etc.

This blog will cover the script to assign a specific Office 365 license to multiple users, based on their UPN.

1. Create a folder on your machine called "Office 365"
2. Create a CSV file with the header of "UserPrincipalName" and then fill the column up with the UPNs of the mailboxes/accounts that you wish to convert to Shared Mailboxes.  Save this as license.csv
3. Open Notepad and add the following contents:
   $AccountSkuId = "<tenantname>:STANDARDWOFFPACK_IW_faculty"
   $UsageLocation = "AU"
   $Users = Import-Csv "C:\Folder\SubFolder\Office 365\License.csv"
   $Users | ForEach-Object {
   Set-MsolUser -UserPrincipalName $_.UserPrincipalName -UsageLocation $UsageLocation
   Set-MsolUserLicense -UserPrincipalName $_.UserPrincipalName -AddLicenses $AccountSkuId
   }
4. Save this file as "AssignOfficeLicense.ps1"

To find out the AccountSkuId, you can use the following Cmdlet:

Get-MsolAccountSku

Simply copy the entire line of the license you want, and paste that here:

Log into Office 365 through PowerShell.  You can follow this blog post to be able to do that.  You will also need to use the final cmdlet in that post to connect to MSOL.

Navigate to the Office 365 folder and then run the .ps1 file with the following command:

.\AssignOfficeLicense.ps1

That will then go ahead and start assigning all the Office licenses to the mailboxes that you have mentioned in the CSV file. 

Thanks to my colleague Gareth Harris for this script.

Convert to Shared Mailbox | Office 365 | Script

Thanks to my colleague Gareth Harris for this script.

I have recently been running a few large-scale (1000+ mailboxes) and I've had to rely on scripts for assigning licenses and converting mailboxes to shared mailboxes etc.

This blog will cover the script to convert mailboxes to a Shared Mailbox, and then remove any associated Office 365 licenses with that user.

1. Create a folder on your machine called "Office 365"
2. Create a CSV file with the header of "UserPrincipalName" and then fill the column up with the UPNs of the mailboxes/accounts that you wish to convert to Shared Mailboxes.  Save this as license.csv
3. Open Notepad and add the following contents:
   Import-csv "C:\Folder\SubFolder\Office 365\License.CSV" | foreach {
   $UPN = $_.userPrincipalName
   Set-Mailbox $UPN -Type “Shared”
   $MSOLSKU = (Get-MSOLUser -UserPrincipalName $UPN).Licenses[0].AccountSkuId
   }
4. Save this file as "ConvertToShared.ps1"

Once you have done this, you will need to sign into Office 365 through PowerShell.  To do this, you can head over to this blog and follow the steps here.

Once you've done this, change your directory to the 'Office 365' folder that you had created.  Then run the 'ConvertToShared.ps1' file.  

.\ConvertToShared.ps1

This will then start the process of converting the mailboxes to 'Shared', and will also remove the licenses if there were any assigned.

Thanks to my colleague Gareth Harris for this script.

Sign into Office 365 | PowerShell

The following commands are used to sign into the PowerShell side of Office 365.  This is mainly for my use as I have to keep Googling where to find it.

$UserCredential = Get-Credential

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic -AllowRedirection

Import-PSSession $Session

If you need to use the MSOL commands, you will need to sign into that too, which you can use the following command:

Connect-MsolService -Credential $UserCredential

Stop Server Manager from showing at logon | RDS

I recently configured a new RDS solution for a client where Server Manager was always popping up when logging in.  I didn't want this to happen for users, so I needed to make the required registry change for this to no longer happen:

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ServerManager

There should already be a DWORD called DoNotOpenServerManagerAtLogon which is set to Decimal: 0.  Simply change this over to Decimal: 1 (as opposed to Hexadecimal: 1) to stop this from happening again.

You will still be able to open up Server Manager, however this won't appear automatically when logging in.

If you require IT Support in the Perth area, contact Winthrop Australia

An Access-Request message was received from RADIUS client x.x.x.x with a Message-Authenticator attribute that is not valid

A client of mine recently had Enterprise Wireless (PEAP) wireless configured which connects to a NPS server to authenticate users connecting up.  People had issues connecting to the wireless after a new Domain Controller was brought online.

Checking the Event Logs, I found the following error:

This indicates that the Shared Secret between the Access Point and what's configured on the NPS (usually a DC) is not the same.  In order to get around this, I checked the settings of each Access Point and updated the Shared Secret.

Once you've done this, log into each access point and update the Shared Secret on to ensure that it's the same.  Once you've done this, the access points should communicate with the DC (or NPS) successfully.

Winthrop Australia provides IT Support in Perth.