Tag: office 365

When i started digging deeper into some aspects of Office 365 i have discovered an interesting and a bit weird (in my opinion) thing. It wasn’t a surprise that some advanced changes are only possible via PowerShell (Microsoft is pushing its shell for many years). But there is no unified, single PowerShell module to manage all the services. You almost have to install and use a separate module for every service. Some of them have different procedures to login. That’s a jarring experience. I will try to describe a few of them that might be useful. Especially when dealing with support, which often asks for an output for some PShell commands on your tenant. Personally i install them all on the same server running Azure AD Connect, as none of my workstations were running 64-bit OS at the moment (and many of these modules, if not all, require x64) and i decided to keep everything related to Office 365 in one place. Read More

Microsoft and its partners advertise Exchange Online and Outlook.com as having one of the best spam filtering. Well, every email service brags about it. But in reality things are not so good. Prior to switching our incoming and outgoing email traffic to Exchange Online we were using a local hosted solution. Well, we are still kind of using it as not all mailboxes have been migrated yet. But all the filtering is done on the cloud side now. Hosted solution consists of Exchange 2013 server and IronPort firewall/anti-spam. This is managed by a service provider and we do not have control of it (aside of creating mailboxes and tweaking some minor stuff). We had a number of filtering rules created for us by our providers. It wasn’t perfect. IronPort seems to not be that flexible. But as we have switched to Exchange Online the hell broke loose.. Well, not that bad actually. But we certainly saw the increase of spam. And sometimes it allowed emails with just a link to “learn how to please your girlfriend” to come through. Well, i wouldn’t call SUCH filtering as a first class service 🙂 Read More

If you have used an on-premises Exchange server before, then moving aliases is a trivial task. But, if you are synchronizing your AD information into Azure AD (e.g. with Azure AD Connect service), so you could assign Office 365 licenses and services to your users, then things become a little bit trickier. As mail aliases and main addresses are the attributes of your internal AD users and the information is only synced in one direction (from your on-premises AD to Azure AD). So, you can’t add or change aliases in the Exchange Online administration center for the existing mailboxes. This change has to be applied in your AD environment and then synced to Azure AD. This can be achieved by opening the AD user properties window and going into Attribute Editor tab (if it is not there, you have to first enable View > Advanced Features in your Active Directory Users and Computers snap-in). In that tab you have to find the ProxyAddresses entry, mark it and press the Edit button. Then you can add or remove aliases. Alias is added in the form of smtp:address@domain.tld. User’s main address starts with a capitalized SMTP part. When you add an alias address in here, it won’t automatically appear in Exchange Online. You have to wait for the synchronization with Azure AD to occur. When using Azure AD Connect automatic synchronization occurs every 30 minutes. You can also do a manual sync with this PowerShell command:

Import-Module ADSync
Start-ADSyncSyncCycle -PolicyType Delta

Read More

Most probably this won’t be important for those who are doing migration to Office 365 services consistently and in full scale. Because DNS records for all services are mentioned when first configuring new Office 365 tenant and creating a special DNS record to prove your ownership of a domain. But as we only needed to assign Office ProPlus licenses at first we have skipped creating additional records. Later, after receiving Skype for Business (SfB) licenses, we have decided to test communication with external SfB and regular Skype contacts. It failed. Although it was enabled in the SfB admin center. But it still was giving an error that some policy is blocking such communication (not a very helpful error message btw). It turned out hat we needed a few special DNS records on our domain to make it work. Examples can be found at Office 365 Admin Center > Settings > Domains > domain.tld. Read More