Christmas time is upon us, and I’ve decided that my PSTeams module needs some love. I wrote it in late 2018 and updated it a few times at the beginning of 2019. This release hopefully is worth of having 1.0 version number. I don’t do that often and usually go for build numbers changes only, but Microsoft Teams message cards have their limits on functionality. Therefore, there are not many things that can be added unless Microsoft opens up and gives us all the cool features of Adaptive Cards. PSTeams module uses Webconnector to send messages to Teams. That method only supports Message Cards, which even Microsoft calls Legacy. But legacy doesn’t mean fully functional with some cool features of their own. If you’re new to PSTeams you may want to read those 2 posts below to get information how to set it up.
In the last few days, I’ve got two reports that my PowerShell module for Office 365 Health suddenly started giving errors. This was a bit weird because it worked perfectly fine on my end. But while I could understand one person having an issue of their own, with their network or firewalls, if the second person comes along with the same report, that means something else is going on.
Today I had a need to connect to Microsoft Graph and do some tasks on Office 365. Since I have already done similar stuff for my PSwinDocumentation.O365HealthService PowerShell module that I’ve described in PowerShell to get all information about Office 365 Service Health, I thought this will be easy run as I’ll just reuse the code I’ve done for that module. As always for Graph related tasks you need to register your application and assign correct permissions. I’ve used my own article for that with changes to which API I want to access. Now that I’ve done all that I’ve extracted my Connect-O365Graph function from my module and started connecting.
Office 365 is an excellent cloud service. But like any service, there’s some infrastructure behind it that has to be cared for. Since this is Cloud, Microsoft does this for you. But any problems Microsoft has to have some impact on your end users. And you may want to have that visibility for your users. Microsoft provides this to Admins when they login to the portal, but while useful you may want to use that data in other ways than those planned by Microsoft.
I’ve been managing mail service for users for a lot of years now. I don’t do it daily but I’ve spent my fair share of time analyzing spam emails. Mail vendors are doing what they can fighting spam, but it’s not easy. Each month, each year spam is getting more sophisticated. Spam emails either look like a legit email, or worse someone is targeting your company trying to get them to transfer money into a wrong account. While most of those end up in spam, there are those that come thru. It’s even worse if the company you work with has not implemented SPF or their SPF is configured to soft fail which can’t be treated as spam.
One of the tasks I often get when setting up new Office 365 tenant or installing Exchange Servers is to change the visibility of Room Mailboxes or in some cases even standard users. There’s nothing hard about it, and there are plenty of articles about it. It’s just three simple steps.
Recently I’m doing yet another migration between Office 365 tenants using Bittitan Migration Wizard. It’s a great tool and takes away a lot of headaches when dealing with the migration of mailboxes or OneDrive data. Unfortunately, like with many blogs on my website I had to hit yet another error. This time error occurred when I tried to assign User Migration Bundle license to users on the Migration Wizard.
Working with Office 365 is my bread and butter in the last few months. I’m a System Architect and I am dropped in multiple projects, both new and old, to fix certain aspect and get out before anyone sees me. One of the common tasks I get is to provide some data about users stored in Office 365.
Last few weeks I’m responsible for migrating from Office 365 to Office 365. Part of this migration process is to set up new Exchange 2016 server that will work as relay instead of using IIS server. I’ve setup hybrid, added accepted domains, prepared connectors, but there’s one thing missing. Any time an email is sent via relay to a user that exists on Office 365 and at the same time exists in Active Directory email never gets there.
MigrationWiz from Bittitan is one of the best tools on the market allowing for migration of user mailboxes. Whether it’s a google account, exchange account or IMAP, it will help you out. Last few months I’m part of migration project that is using Bittitan at its core. One of the signature features of this tool is the ability to migrate mailboxes from Office 365 tenant to Office 365 tenant. This is not something that every application can do. Another feature (and something I want to address today) is the ability to ask users for their logins and password to migrate their data from one tenant to another tenant. While in general, you shouldn’t do that and you should use migration accounts with proper permissions sometimes you have no other choice.