Tag: Office 365

Enable Exchange Mailbox Auditing for all users

Enabling Mailbox Auditing as an Exchange Administrator has for a long time been something you have need to do manually.

Yesterday, Microsoft announced that they will be enabling mailbox auditing by default for all user mailboxes using Office 365 and Exchange Online. This is a welcome change, so you don’t need to manually enable mailbox auditing on new users or use a script that enables that for all users in Office 365 and Exchange Online.

For on-premises Exchange environment, there is no such feature (hopefully it will come with a future Cumulative Update) so you still need to change it manually. Either you add this as a process when creating a new mailbox, or you can use a PowerShell script as an Schedule Task on your Exchange Server that will automatically enable auditing.

Here’s an example on how such script can look like, and you can find it as a download here.



Device cleanup rules for Microsoft Intune

As an IT Administrator you want to keep your IT environment clean and tidy and the same goes for Microsoft Intune.

By default all devices that has been inactive or stale and hasn’t checked in for over 270 days will automatically been removed from the console.

In the latest update for Microsoft Intune dated July 2, Microsoft included a new feature, Device cleanup rules:.

New rules are available that let you automatically remove devices that haven’t checked in for a number of days that you set.

 

You will find it in the Intune pane, select Devices, and select Device Cleanup Rules:

By default, this is not enabled, so you need to change it to Yes and specific the numbers of days between 90 and 270 that suites your company’s policy and requirements.

If nothing is changed or you remain it set to No, it will use the default 270 days:



App Protection Policies for managed and unmanaged devices in Intune

In the latest update of Microsoft Intune, you now have the option to target App protection policies for Mobile apps if the device is Intune managed or if its unmanaged.

The two options that for now is available, if you select not to target all app types are:

  • Apps on unmanaged devices
    Unmanaged devices are devices where Intune MDM management has not been detected.
  • Apps on Intune managed devices
    Managed devices are managed by Intune MDM and have the IntuneMAMUPN app configuration settings deployed to the app.

With this new update, you are now able to create required settings for devices that are fully managed by Intune and separate policy for devices not managed by Intune.
For example you could allow saving files locally on devices managed by Intune and only allow saving to OneDrive or SharePoint (which is protected by App protection policies) on devices not managed by Intune.

If you are interested in learning more about App Protection Policies, you read more on docs.microsoft.com or drop a comment below!



Block external access for Service Accounts using Conditional Access in Azure AD

Conditional Access in Azure Active Directory is normally used for users and administrators to secure and control company data in Office 365 and Azure, but what about Service Accounts? Aren’t they a potential security risk?

Using Service Accounts for scripts and other tasks related to Office 365, Azure and Azure AD is a normal practice along companies, sometimes the accounts has full administrative permissions (Global Admin for Office 365, Owner of a subscription/resource group in Azure) and sometimes the accounts has delegated privileges but they all have more permissions than a regular user.

In this post we will cover how you can use Conditional Access to block sign-ins from service accounts outside the company main datacenter to make sure they are only used on servers located on networks that the company has control over.

  1. Open portal.azure.com and go to Azure Active Directory and Conditional Access under Security
  2. Go to Named locations and Add the external IP address of the data center(s) that should be allowed for the service accounts to sign-in from.
  3. Create a new policy and name it “Block external access for service accounts
  4. Select the Service Accounts or an Azure AD Group, in our case we use a groups that will contain all the service accounts
  5. In Cloud apps, select All cloud apps
  6. For Conditions, select Locations and Configure. Select Any location in the Include tab
  7. Also in Conditions and Locations, select the Exclude tab and select the location of the data center added in step 2.
  8. For Access, go to Grant and select Block access
  9. Select On for Enable policy, and verify all settings before creating it.
  10. The policy should now look like the following:
    Conditional Access policy - Block external access for service accounts

    Conditional Access policy – Block external access for service accounts

     

You can find out more about Conditional Access on docs.microsoft.com:

https://docs.microsoft.com/en-us/azure/active-directory/active-directory-conditional-access-azure-portal 



Sending CSS formatted tables in Outlook

If you’ve ever used Powershell to send HTML tables in Outlook containing CSS you’ve probably been disappointed of the outcome.
There is some archived documentation for Outlook 2007 that is still viable for Outlook 365 (https://msdn.microsoft.com/en-us/library/aa338201(v=office.12).aspx).

Basically the function accepts a csv and css file, hardcodes the css into the table and outputs a formatted HTML table that is compatible with Outlook.

Example table sent using the function and send-mailmessage
The css has odd/even for readability, bolded column 1/4 and red text for column 3.
This is by default impossible to achieve using just css in outlook.

Commandline

HTML output

CSS

Since the CSS does not work perfectly the style.css file imported needs some specific configuration..

  • classes has some specific name structure”
    • columns are named .coln
      • n is the number of the column starting with 1 to infinity. .col1 .col2 and so on
    • one whitespace is required between class name and the curlybrackets.
      • Curlybrackets must be on the same row as class name
      • Ending curlybrackets must be on a separate line
    • Data must be on separate rows
  • Odd/even css is the only tr handled code.
    • Must be named exactly
      • tbody tr:nth-child(odd) {
      • tbody tr:nth-child(even) {

Example style.CSS

Function

 



Exchange Online mailbox move – Unable to connect to Remote MRS proxy server

Recently in an Exchange Hybrid environment with Exchange Server 2016 on-premise and Exchange Online in Office 365 I encountered the following error message when trying to move a mailbox from on-premise to Exchange Online using New Migration Batch on Remote MRS proxy server:

”The connection to the server ‘mail.domain.com’ could not be completed”

On the on-premise Exchange Server I ran the Test-MigrationServerAvailability command with the following parameters to verify the availability with migrating cross-forest:

The result returned with Failed and looking at the error message, we can see the following:

The call to ‘https://mail.domain.com/EWS/mrsproxy.svc’ failed”.

Trying manually to go to the URL, it returned with an error code of: ”Server Error in ‘/EWS’ Application.”
Normally it would have returned ”The webpage cannot be found” with an 404 error code.

Going to the on-premise Exchange Admin Center, Servers > Virtual Directories > EWS (Default Web Site) I wanted to verify that MRS is enabled for that server – but as the picture shown below, it wasn’t.

I enabled the MRS Proxy Endpoint for the server by selecting the checkbox and press Save:

Restarting the WebAppPool MSExchangeServersAppPool on the specific server using the following command to make sure everything applied and any cache are cleared:

Going again to the URL https://mail.domain.com/EWS/mrsproxy.svc I now received the correct ”error code” of ”The webpage cannot be found” and 404.

Rerunning the Test-MigrationServerAvailability command, I now received a Success as the result:

Going back to the new migration batch, I could now proceed with the move of the mailbox to Exchange Online.



Office365 med FSLogix i en fleranvändarmiljö

Eftersom Microsoft hårdsatsar på molnet och Office 365 har det länge varit ett naturligt steg att flytta sin on-prem Exchange till molnet – Exchange-Online i Office 365 för att kunna nyttja de många fördelar den erbjuder. Men det har i vissa fall inneburit försämrad upplevelse för slutanvändarna. I och med att Exchange nu befinner sig i Office 365 (Azure) har svarstiden ökat generellt. I många fall har en svarstiden ökat med en faktor om 10. Detta medför att navigering mellan mejl (när man använder förhandsvisaren aktiverad) är seg, det kan ta någon sekund för att det nya mailet man navigerar till dyker upp. Upplevelsen av Outlook blir påtagligt sämre och effektiviteten i sitt dagliga arbete påverkas.

Outlook Cached Mode

En lösning på problemet har varit att helt enkelt slå på Cached mode och helt blir av med problematiken av hög svarstid, detta fungerar väldigt väl med alla som har en ”fet klient” och har diskutrymme lokalt. I en fleranvändarmiljö blir det lite mer komplicerat, för att kunna köra cached mode i en fleranvändarmiljö såsom Citrix eller Microsoft Remote Desktop Services (RDS) måste man först kunna hantera stora mängder data eftersom fler och fler användare har väldigt stora mejllådor, profilstorlekarna blir dessutom väldigt stora och påverkar bland annat inloggningen negativt. För att komma runt detta riktar man om Outlook cachen (*.OST-filen) till ett lagringsyta (vanligtvis en filserver) som har kapacitet för lagringen och det i sin tur kommer inte belasta fleranvändarmiljön.

Många som kom fram till denna lösning har i sina tester haft mycket bra resultat, i en testgrupp på säg 20 personer fungerar detta mycket väl och implementering i sin produktionsmiljö är ett faktum. Men dessvärre slutar det inte här, det som kan vara svårt att förutspå är hur mycket den konstanta indexeringen av ost-filen belastar CPU:n och hur mycket nätverkstrafik SMB protokollet använder vid en sådan frekvent uppdatering av ost-filen, för att inte tala om vad Windows Search gör i en sökning av din mejllåda. All denna kraft står nu filservern för, som oftast inte är dimensionerad för detta, så som en Exchange-server är. Så när man produktionssätter sin lyckade lösning med 100+ användare blir resultatet ännu sämre än innan.

Detta är ett stort problem som många upplever och något som man har velat se en lösning på i många år, men det har dessvärre aldrig funnits någon lösning från Microsoft för detta. Det är här FSLogix Office 365 Containers kommer in i bilden.

FSlogix Office365 Containers

FSlogix är kortfattat ett företag där de tog saken i egna händer. De har utvecklat en produkt som löser alla problem ovan riktigt snyggt. Själva installationsförfarandet är mycket enkelt, du installerar en agent på alla servrar dina användare loggar på, lägger till ADMX tillägget i din Group Policy manager för styrning via GPO och pekar ut den filyta du vill att cachefilerna ska lagras.

Agenten kommer nu automatiskt peka om alla cachade filer till denna filyta (oavsett vad du definierar i Outlook). Det som FSLogix gör är att den skapar en vDisk för varje användare som vid inloggning kopplas på din session, det underlättar nätverksbelastningen avsevärt i jämförelse med SMB till en filserver, de har dessutom utvecklat intelligens för själva OST-filen som i grund och botten är en databas som konstant uppdateras. Den har ett slags mellanlager som sköter uppdateringen av OST-filen effektivare och snabbare, vilket gör att CPU belastningen blir en bråkdel av alternativet. Någon som också var en nyhet i våras som var mycket efterlängtat är att den även nu stödjer Windows Search så att din Cachade OST-fil är sökbar i Outlook.

FSLogix är ett mycket bra komplement för Exchange-Online i fleranvändarmiljöer!

OneDrive

I samma licens får man även tillgång till deras cachning av OneDrive, den lägger sig i samma vDisk som för Outlook och eftersom OneDrive börjar bli en bra produkt som fler och fler företag börjar använda är detta en mycket trevlig bonus.

 

 

Vill ni läsa mer om FSLogix Office365 Containers kan ni trycka här!



Guest access in Microsoft Teams

Yesterday Microsoft made one of the most request feature for Microsoft Teams general available, Guest Access for external users.

Guest access allows you to add people from outside your company and organisation to a team, so they can participate in chats, join meetings, collaborate on documents and more.

At the moment, anyone with an Azure Active Directory (Azure AD) or Office 365 work or school account can be added as guest in Teams. Microsoft will later on add the ability to add anyone with a Microsoft Account (MSA), like Outlook.com or Live.com.

Image: blogs.office.com

Enable Guest Access

To enable Guest Access in Microsoft Teams, an Office 365 Administrator will have to logon to Office 365 Admin Center and go to Microsoft Teams under Services & add-ins and change Settings by user/license type to Guest and turn the feature On.

 

Inviting a guest

To invite a guest user to a team, just add the user as you normal do by entering the email address:



Skype for Business will be upgraded to Microsoft Teams

Last night, a couple of Office 365 users received the following popup in the portal that Skype for Business is now Microsoft Teams and they should start using Teams:

In the Office 365 Admin Portal, MC118018 was published by Microsoft and later removed, stating that they are starting to upgrading Skype for Business to Microsoft Teams.

The notice stated that for now, this is an opt-in experience, so it’ls not an immediately change by Microsoft, but as an action is required by 2018-09-07 it sure looks like you will be forced to upgrade.

There have not been an official announcement from Microsoft, yet but as Microsoft Ignite is less than a month a way we might see a few new announcements there and one of them might be that Skype for Business will be upgraded to Microsoft Teams.

Source



Office 365 smart links with NetScaler and ADFS

A common issue in organizations moving to Office 365 is the different URLs the users have to remember. This can be made easier by for example smart links, where the users only have to remember something like ”office.example.com” or ”onedrive.example.com”.

This is something we can easily do with NetScaler and ADFS. See below for a few examples.

First, create a few pattern sets and expressions to reflect the different host headers:

In this case, they will do the following:

  • adminportal.example.com will point to portal.office.com but not use SSO in ADFS (internally), but rather allow the user to enter username and password.
  • portal.example.com will point to portal.office.com and use SSO in ADFS (internally)
  • onedrive.example.com will point to OFFICE365TEANANT-my.sharepoint.com
  • sharepoint.example.com will point to OFFICE365TENANT.sharepoint.com

Next step, create the responder actions. Different for internal and external usage:

In my case, I’ve added the ability to enter add a query string to onedrive, which forwards it to ADFS. For example, you’ll be able to go to https://onedrive.example.com/?username=simon and it will be entered in ADFS for you. Great to use in combination with other tools that already knows you username. Don’t forget to change adfs.example.com and OFFICE365TENANT to your own.

Now we’ll create the responder policies and policy labels:

 

And as a last step, bind these policy labels to vserver, in my example to content switching vservers:

Please leave a comment if something doesn’t work as expected or you have some enhancements that can make this work even better! I’ve tried it with ADFS on Windows Server 2012 R2.