Administrators have always been able to access user content and don’t need eDiscovery functionality to do this. Administrators can log onto someone’s mailbox or give themselves permission to access a user’s OneDrive account, or use the Search-Mailbox cmdlet to copy messages from user mailboxes to another mailbox. And they can run content searches to scan mailboxes, SharePoint, OneDrive, Teams, Office 365 Groups, and public folders and export whatever they find to PST files, ZIP files, or individual files. In short, many ways are available to an Office 365 administrator to poke around in user content if they so wish. Continue reading → Verifying Administrator Access to Office 365 User Data
Earlier this month, Microsoft disclosed that Teams now boasts an official solution for archiving.
To archive a team, click Teams in the navigation bar in the desktop or browser client to expose the list of teams, then the Manage cogwheel icon under the list of teams. You see a list of teams that you belong to, divided into active teams and archived teams. You can only archive a team when you are an owner of that team. The choice to Archive team is in the ellipsis menu for the team. Continue reading → Archiving Teams
Microsoft’s announcement that the Exchange Hybrid Configuration Wizard (HCW) is now able to transfer some configuration settings from an Exchange on-premises organization to Exchange Online came as a disappointment. Not because of the functionality, which is welcome, but because it is limited and far too late. Continue reading → Hybrid Configuration Wizard Transfers Settings – Sorry bit late now
Capturing Compliance Data Since January
Neatly aligned with the need for better compliance mandated by GDPR, Microsoft announced on June 1 that they have been collecting compliance records for messages sent by on-premises users in personal chats since January 31, 2018. Microsoft says that they are working to create compliance records for chats before this date but cannot commit to when this data might be available. Continue reading → Teams Can Now Capture Compliance Records for Hybrid & Guest Users
Microsoft’s original vision for Office 365 Groups emphasized openness. Anyone could create a group and all groups were public. The aim was to foster collaboration and make sure that anyone could join in any group discussion as they liked.
Time passes by and software matures in the fierce heat of customer opinion. The original dedication to openness is less than it was. A group creation policy allows tenants to restrict the creation of new groups to a limit set of users. Teams hides groups that it creates from Exchange clients to avoid the chance of confusing users and Yammer-originated groups are invisible anywhere outside Yammer.
And now, Microsoft has decided to change the default access type for a group from public to private to satisfy the third-highest rated request for Groups on Uservoice, the place where customers voice their opinion about changes they’d like Microsoft to make.
A hybrid deployment offers organizations the ability to extend the feature-rich experience and administrative control they have with their existing on-premises Microsoft Exchange organization to the cloud. A hybrid deployment provides the seamless look and feel of a single Exchange organization between an on-premises Exchange organization and Exchange Online in Microsoft Office 365. In addition, a hybrid deployment can serve as an intermediate step to moving completely to an Exchange Online organization.
But one of the challenges some customers are concerned about is that this type of deployment requires that some communication take place between Exchange Online and Exchange on-premises. This communication takes place over the Internet and so this traffic must pass through the on-premises company firewall to reach Exchange on-premises.
The aim of this post is to explain in more detail how this server to server communication works, and to help the reader understand what risks this poses, how these connections are secured and authenticated, and what network controls can be used to restrict or monitor this traffic. Continue reading → Deep Dive: How Hybrid Authentication Really Works
In Azure AD Connect, the default synchronization interval is set to 30 minutes during installation. In the majority of cases, 30 minutes is an appropriate balance between getting changes to Office 365 in a timely fashion, keeping the export set small enough to be effectively transmitted, and not overloading the on premises directories or Azure Active Directory.
The configuration of the Azure AD Connect synchronization schedule can be viewed using Get-ADSyncScheduler.
PS C:\> Get-ADSyncScheduler
AllowedSyncCycleInterval : 00:30:00
CurrentlyEffectiveSyncCycleInterval : 00:30:00
NextSyncCyclePolicyType : Delta
NextSyncCycleStartTimeInUTC : 1/23/2018 2:58:30 PM
PurgeRunHistoryInterval : 7.00:00:00
SyncCycleEnabled : True
MaintenanceEnabled : True
StagingModeEnabled : False
SchedulerSuspended : False
SyncCycleInProgress : False
My Office 365 admin portal displayed a new recommendation when I logged in last week. Microsoft is recommending that user account passwords be set to never expire. My tenant is currently set to an expiry period of 90 days, whereas a newer tenant I was doing some testing with last month has defaulted to 730 days. I am not sure whether a tenant created today will default to 720 days or to non-expiring passwords.
This recommendation has so far appeared only in tenants that I have access to that are configured with First Release for everyone, and that aren’t enabled for directory synchronization. I imagine that the recommendation is being rolled out slowly.
The thought of non-expiring passwords might raise a few eyebrows in some organizations. For a long time the accepted position for passwords was to change them regularly. This thinking comes from a time when passwords were the single factor of authentication for most systems, with multi-factor authentication being relatively rare. Times have changed though, and recent research has concluded that requiring users to change their passwords regularly will usually lead to them:
- choosing weaker passwords to begin with, because they don’t want to learn complex new passwords each time they are forced to change it
- choosing new passwords that are only a minor variation of their previous password, e.g. Monday01 changes to Monday02
So what should we do if we aren’t requiring our users to regularly change their passwords? Continue reading → Microsoft Recommending Non Expiring Passwords to O365 Customers
With the news at Microsoft Ignite that Teams is here to stay, and going to be the primary collaboration client in Office 365, it is going to be important for organisations to understand how to secure the data and conversations stored within Microsoft Teams.
Where is the data?
The first key thing to understand what types of data you are talking about, and where it is actually stored. Every “Team” is build on an Office 365 Group, and this is where the majority of the Team related data will be stored. Each Channel in the Team will provision a new folder in the Group’s Document Library, and this is where files shared in Group conversations will be stored. Each Group also has a Group Mailbox, and this is where conversations held within channels are stored.
However, users can also communicate directly via chat, and share files from this interface. In this instance, the conversations will be stored in the user’s mailbox, and the files they share will be stored in OneDrive.
That’s great, but what does this mean when it comes to compliance? Continue reading → How to Secure Conversations and Data in Microsoft Teams
Microsoft have announced that Azure Site Recovery (ASR) is now built into the virtual machine experience so that you can setup replication in one click for your Azure virtual machines. Combined with ASR’s one-click failover capabilities, its simpler than ever before to setup replication and test a disaster recovery scenario.
Using the one-click replication feature, now in public preview, is very simple. Just browse to your VM, select Disaster recovery, select the target region of your choice, review the settings and click Enable replication. That’s it – disaster recovery for your VM is configured. The target resource group, availability set, virtual network and storage accounts are auto-created based on your source VM configuration. You also have the flexibility to pick custom target settings. You can refer to the animation below for the flow.
If you have applications running on Azure IaaS virtual machines, your applications still have to meet compliance requirements. While the Azure platform already has built-in protection for localized hardware failures, you still need to safeguard your applications from major incidents. This includes catastrophic events such as hurricanes and earthquakes, or software glitches causing application downtime. Using Azure Site Recovery, you can have peace of mind knowing your business-critical applications running on Azure VMs are covered and without the expense of secondary infrastructure. Disaster recovery between Azure regions is available in all Azure regions where ASR is available.