Add Office 365 Calendars to Google Calendar

November 3, 2017 Josh Reichardt 1 Comment

I ran into a scenario recently where I wanted to be able to combine both my work (Office 365) and personal (Google Calendar) calendars, which I found to be a really painful process. Likewise, the information on the web turned out to be equally painful. The main motivation for doing this is so that I can sync all of my calendars to my (Android phone), so that when I’m away from the computer I can easily see what is on both my personal schedule as well as the work calendar.

Since I started using Office 365 I have found a number of small annoyances, and this post servers to illustrate a good example of one. Office 365 is a good product, there are just certain things that are needlessly confusing and complicated as well as a few things that could just work better out of the box. My opinion is probably also skewed, due to the fact that I haven’t used any of the Microsoft Office online offerings for a while now.

The first step is to publish/export the calendar on the Office 365 side of things. The setting to export the calendar is completely buried in the O365 web app but can be located by navigating to Settings -> Your app settings -> Calendar

This should open a navigation menu on the left with more options. From here you can find Shared Calendars -> Publish Calendars settings.

From here you can select which Office 365 calendar you’d like to publish and also the permissions to share. Once those options have been chosen, you can save and a link will be generated for both the HTML and ICS versions of the calendar.

It turns out that only the ICS link will work on the Google Calendar side of things. I did have some trouble when I was playing around with the HTML version, which turns out is because Google doesn’t cooperate with HTML calendars, only ICS.

Now you can import the ICS calendar on the Google Calendar side of things. There are a few ways to do this. Pull open the settings in Google Calendar and either use the Import & Export feature to upload the ICS file generated above or add the ICS URL to the shared calendar using the Add Calendar -> From URL option. Note again that the HTML version of the URL won’t work.

Using either the ICS web link or importing the calendar using the ICS file should work. And after adding the calendar in Google you should see all of the events pop up and if you look at your calendar on your phone, the events should be present. The sync can sometimes take a few minutes, so if they don’t show up right away just wait a bit (or sync them manually) and if you created a new calendar you might need to turn it on.

NOTE: If you add the calendar using the ICS import method, you will not have any way to delete “unmerge” the calendars. Basically, you will have to manually delete the items that were imported from the ICS file if you want to get rid of them permanently. If you create a work calendar in Google Calendars and import the ICS there, it will probably be a lot more manageable.

This solutions feels a little bit clunky but it is good enough for me, and there doesn’t seem to be a good work around for sharing the Office 365 calendar with Google. If there are any good Android apps that can add calendars from different providers let me know, that would probably work just as well but I didn’t really need to look after putting this workaround together.

Monitoring email flow with MFM

May 1, 2017July 17, 2019 Josh Reichardt Leave a comment

This is a sponsored post by the folks over at EveryCloud. They have recently developed and released a new tool to help manage and troubleshoot email issues, which is starting to get some traction, especially among Exchange environments. As a mail admin in a previous life, I can sympathize with desire for better monitor tools. Here’s their post.

Managing mail flow is a challenge for every systems administrator, and the price of a mistake is very high. Any interruption in mail flow can spell disaster for a company, disrupting daily operations and leaving the management team, the IT team and the systems administrator scrambling for solutions.

While there are a number of mail flow solutions on the market, they tend to be quite pricey, making it difficult for systems administrators, especially those who work for small businesses and start-ups, to justify the cost.

For those who do not already know, the makers behind the EveryCloud mail flow monitor have recently launched a free service – Mail Flow Monitor (MFM). EveryCloud MFM tool is the only free round-trip mail flow monitor on the market, giving systems administrators the ability to observe their organizations’ email systems 24 hours a day, 7 days a week and 365 days a year, all without spending a penny.

Some of the features of Mail Flow Monitor include:

A full-featured round trip monitor, with start-to-finish email tracking and monitoring
Systems administrators can receive real-time text and email alerts whenever a delay or rejection occurs – to your cell phone as well an email or to your alternative email address.
Timely monitoring means issues can be addressed quickly, before they spiral out of control
The system sends a test email every few minutes to a monitoring mailbox on your server. You set up a forward to send the emails back and the Everycloud team does the rest.
MFM is cloud based, which means there is nothing to update or manage.
MSP’s and IT Resellers can create an account and manage as many customers as they wish via the EveryCloud Partner Area, all completely free!

When you consider that competing mail filtering solutions generally cost about $30 a month, it is easy to see the saving potential. That $360 annual cost savings may not seem like much, but since it is assessed on a domain level, the charges can add up quickly. In addition, the per-domain charges can make managing a complex IT operation difficult, an extra level of hard work that systems administrators do not need.

From the smallest startups to the largest multinational corporations, modern businesses live and die on their email. An unexpected email breakdown, significant bottleneck or major failure could make the firm’s email inaccessible and unreliable for hours or even days, and every minute of downtime is costing the company money.

Exchange Transport Service won’t start

February 17, 2014August 31, 2015 Josh Reichardt 13 Comments

Due to an outage this weekend, I’d like to take a minute to briefly describe the scenario that occurred and how it was resolved. If you are having trouble starting your Exchange Transport Service then you may potentially be running into the same issue I was having during the outage. Luckily there is an easy remedy for the service failing to start. Basically what was happening was the Exchange message queue database was beginning to fail due to some sort of corruption, causing the Transport service to fail. Because the Transport service wasn’t running, the Edge Sync process was failing, causing external mail delivery to fail. Obviously a big issue, since you cannot receive any email from external domains if this is not working correctly.

To troubleshoot this, there are a few obvious signs that you should look at first. The main thing you should check first is your disk sizes, I wrote about it in my previous post. If your disks are full or are filling up then you are pretty much dead in the water and will need to fix your disk issue. In my scenario the disk sizes were not an issue so the next tool I turned to were the logs. I found a number of interesting entries in the Windows Application Event logs that gave me some clues. I want to detail as many of these messages as I can so that people who are having similar issues know what to look for.

There are a few possible resolutions to this problem. Through some Google searches one solution I found is that you can attempt to repair the corruption in the queue databases by running the database through ESE util. There is no guarantee this will work and it can potentially take a lot of time, depending on the size of your queue database. There is some good information here about the mail queue and how it works.

If you decide to repair the database, the mail queue file is located in the following location:

C:\Program Files\Microsoft\Exchange Server\V14\TransportRoles\data\Queue

Inside this directory is a file called tmp.edb. This is the file that you will need to repair.

The other method is much simpler and was the solution I went with. Instead of attempting to repair the database corruption, simply copy and rename the queue folder and restart the Transport service. Doing this will force the Transport service to create a new, fresh copy of the database queue along with all of the accompanying config files and associated items that are required to get things up and running. It is faster and simpler, IMO. The only problem with this approach is that items that were stuck in the queue when the database corruption occurred will be lost. For me, this was an acceptable loss. If not, you will probably have to use the first method and attempt to repair the database or try to somehow work with a shadow copy or backup somehow to get unstuck.

Monitor your Exchange disk sizes

February 11, 2014August 31, 2015 Josh Reichardt 11 Comments

A word to the wise. If you all of a sudden are unable to send and receive email messages in your Exchange environment, take a look and make sure the Exchange server disks aren’t being filled up. Today I ran across an interesting (and by interesting I mean that this could have caused a serious outage) issue where Windows updates were very routinely being downloaded for our next patch management installation cycle but unknowingly were also causing our email services to stop functioning correctly. I am thankful the scenario didn’t get ugly and luckily this event gives me the opportunity to talk about a few of things that I think might be useful for readers and other admins.

It turns out that this month’s wave of Windows updates caused the disks on our Hub Transport servers to quietly fill up during the day, unbeknownst to any of the admins. In normal circumstances this process is by design and almost never becomes an issue, however in this case there was not enough disk available for Exchange to work correctly. This could have been disastrous had we not known that the disk was starting to fill up. We could have been chasing our tails for a much longer period of time and the situation could have escalated to a more stressful situation. For some reason, the company likes to be able to send and receive emails. Thank god for monitoring that works.

There are a couple things that need to be investigated at this point. First, had we not known that the Windows updates were what were causing the disk to fill up, a logical place to start looking for clues would be to examine the log files on the suspect servers. I would like to take a little bit of time and quickly go over some steps for looking at logs in an Exchange environment, when thinking about potential disk space issues a few things come to mind. Are log files growing rapidly? Did somebody turn on verbose logging and accidentally forget to turn it off? To verify the logs aren’t the issue there are a few places that are good to look. If you are familiar with or have ever used message tracking in Exchange you know how powerful it can be. Sometimes that can also potentially be an issue with your disk filling up. Here is the location that these message tracking logs are stored:

C:\Program Files\Microsoft\Exchange Server\V14\TransportRoles\Logs\MessageTracking

Another location that gets used when you turn on verbose logging for troubleshooting send or receive connectors are the smtpsend and smtpreceive directories. These can fill up quite quickly if you forget to turn off verbose logging on a send or receive connector when are you done troubleshooting. This location is here:

C:\Program Files\Microsoft\Exchange Server\V14\TransportRoles\Logs\ProtocolLog

Finally, there is a location for logging protocol settings on the hub transport. These logs can be found here:

C:\Program Files\Microsoft\Exchange Server\V14\TransportRoles\Logs\ProtocolLog

I would like to point out quickly that any and all of the behaviors of these logging methods can be modified using the Exchange Management Shell, and sometimes for more detailed settings can only be modified by the EMS.

If these quick spot checks don’t uncover any immediate problems another good technique to help gain some insight into where your disk space issues are is to use a tool that enumerates file locations and file sizes. There are a few tools available, one of them I like to use is Space Sniffer. It is fast, easy to use and gives a good visual representation of directory sizes and file sizes. The tool can do much more but in this case we are just interested in finding the disk issue quickly. We were able to quickly find that the size and contents of the %windir%\softwaredistribution\download folder were growing rather quickly. I just happen to know that this is the temporary location that Windows uses to store Windows update files before they are installed.

There are a few things that can be done here. You can either clear the temporary Windows updates files, delete other unnecessary files or you can grow your disks. We were lucky because our Hub Transport servers are VM’s and increasing the disk size of these servers is simple. That seems like the best option if it is a possibility, just in case something like this happens again we will have the additional space so the Exchange servers won’t bog down.

Ultimately we prevented the disaster from occurring but the incident is a great illustration of the lesson I’d like to share. Make sure you have a good monitoring and alerting solution in place. Otherwise you may not have any clue where to start looking. If we did not have a reliable monitoring tool in place it would have been much more difficult to track this problem down in the first place because our Exchange environment is large and complex. Because we have good monitoring tools we were able to quickly identify the problem and resolve it before anything bad happened. On a side note, I am still thinking about how we can take this monitoring and alerting one step further in the future to become proactive instead of reactive but for now the monitoring tools are doing their job and because of this we avoided a potential disaster. If you have any thoughts on proactive monitoring and alerting relating to these types of disk issues let me know, I’d love to hear how you handle it.

Gathering Exchange 2010 mail flow statistics

December 17, 2013January 14, 2018 Josh Reichardt 95 Comments

Tech Tip: Work on your windows compatible monitoring software with SharePoint or Exchange Add-on using cloud based virtual desktops accessible remotely from your (PC/Mac/iOS/Android) devices with CloudDesktopOnline.com and get complete access to MS office on the same desktop by visiting O365CloudExperts.com powered by Apps4Rent.

There are times when it can be useful and beneficial to have a good grasp on the details of what kind of mail traffic is running through your Exchange environment. Recently I have been tasked with coming up with some environmental statistics for our Exchange 2010 servers to help size a new project we are starting soon. There are a few different tools to help gather this information that I’d like to briefly go over today. Before I start I’d like to point out that most of this stuff I am borrowing from others, however I think it is valuable to know how to do this type of thing. With that said, I’m definitely not trying to take credit for any of these techniques, just trying to show the benefits.

There are a few different tools that will help to get a handle on your Exchange environment. The first and quickest way to peer into your Exchange environment for some quick high level overview statistics is to use PowerShell.

The following command can be used to grab some basics statistics such as the total mailbox size, average mailbox size, the max and the minimum sizes in your environment.

Get-Mailbox -Database MBDB1 | Get-MailboxStatistics | %{$_.TotalItemSize.Value.ToMB()} | Measure-Object -sum -average -max -min

It is important to note however that this command can take some time to complete and can be an intensive process because there are so many calculations going on, just be careful that you don’t crash anything. This command may not be viable if the environment is enormous but if that is the case you probably don’t need to use any of these techniques anyway.

The next useful tool to gather up mail flow information uses the Microsoft Log Parser tool, which can be downloaded here. The log parser basically allows us to query the Exchange message transport logs to pull out interesting information. I found a great blog post that describes the process of using the log parser tool to query the message tracking logs to help determine daily send and receive traffic in your Exchange environment. You can find the blog post here and I have it reference at the end of this article as well.

There are a few tricks however that I would like to mention because a few things in the blog post aren’t exactly obvious. After downloading and installing the Log Parser you must run the command he has listed on his site using CMD, otherwise you will have to modify his commands to use PowerShell.

For this command to work correctly you must also navigate to the correct location where the transport logs are being stored. In the default install of Exchange they are stored in:

C:\Program Files\Microsoft\Exchange Server\V14\TransportRoles\Logs\MessageTracking

So after you navigate to the correct location you run the command:

"C:\Program Files (x86)\Log Parser 2.2\logparser.exe" "SELECT TO_LOCALTIME(TO_TIMESTAMP(EXTRACT_PREFIX(TO_STRING([#Fields: date-time]),0,'T'), 'yyyy-MM-dd')) AS Date, COUNT(*) AS Hits from *.log where (event-id='RECEIVE') GROUP BY Date ORDER BY Date ASC" -i:CSV -nSkipLines:4 -rtp:-1

This will output the total number of send/receive messages for each date for the last 30 days on that particular server. Another important thing to keep in mind is that you need to run this command on each server that has either the Hub Transport or Edge Transport role installed because each server houses a unique set of log files.

The last technique I’d like to go over for gathering interesting Exchange mail flow information is a script I found online, which can found here. This is a very robust script that gathers a lot of specific information for a particular set of logs files. Essentially this script functions similarly to the above Log Parser, except it grabs a lot more detail for a particular date.

This is easy to get working, just copy the script from the link into a .ps1 file and save it to a server that has the Exchange Management Shell installed on it. If the EMS is not installed then this script will not function correctly. The script will output some interesting details for each individual user including things like:

Username
Messages sent/received
Total MB sent/received
Internal sent/received stats
Unique messages sent

And output this information into a CSV file so it easy to manipulate the data at that point. This kind of stuff is very useful in helping to determine things like average sent and received message size for example, I have not been able to provide that information to management easily until I found this script.

There are more techniques out there I’m sure, maybe even software that helps gather these sorts of stastics and information but for a quick and dirty way to grab some high level statistics you can’t really beat these techniques. These methods are quick and will get you the information you need, which more often than not seems to be at least as detailed as the people requesting this information are looking for which is a win-win for everybody. If you have any other input or questions about mail flow statistics feel free to let me know.

Resources:

http://exchangeserverpro.com/daily-email-traffic-message-tracking-log-parser/
http://exchangeserverpro.com/exchange-2010-message-tracking/
http://gallery.technet.microsoft.com/scriptcenter/bb94b422-eb9e-4c53-a454-f7da6ddfb5d6