Enable the Infrastructure Backup Service through the administration portal so that Azure Stack can generate backups. You can use these backups to restore your environment using cloud recovery in the event of a catastrophic failure. The purpose of cloud recovery is to ensure that your operators and users can log back into the portal after recovery is complete. Users will have their subscriptions restored including role-based access permissions and roles, original plans, offers, and previously defined compute, storage, and network quotas.
However, the Infrastructure Backup Service does not backup IaaS VMs, network configurations, and storage resources such as storage accounts, blobs, tables, and so on, so users logging in after cloud recovery completes will not see any of their previously existing resources. Platform as a Service (PaaS) resources and data are also not backed up by the service. Continue reading
Over the last few years, I’ve seen a significant increase in the number of businesses moving from on-premises Exchange environments to Office 365. That move makes absolute sense. When it comes to messaging, there’s hardly any difference (in terms of business value and competitiveness) whether you run it yourself or consume it a service.
But one area in particular does make a difference: backup and restore. Continue reading
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
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
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
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
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
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