Well this is quite a generic error that you might encounter with a lot of different products. However, I was so lucky that I got this error while working with Microsoft Powerautomate, Which was also known is Orchestrator back in the days. So let me describe what I was trying to do while I encountered the error, and then I can share the solution.
Recently I was working for a customer who have had an external consultant set up out of office(OOF) on a couple of shared mailboxes. However, as this was done a couple of years ago, it was not possible to get hold of the consultant who had originally set up the solution. It sounds quite easy, that between 16:00-08:00 and weekends (non-Office hours) send a OOF to whomever sends an email! The obvious choice seems to be Powershell script, scheduled somehow! If you just search for the term, you will find hundreds if not thousands of search results on Google (you might even find some on Bing 😉 if you are one of the Microsoft advocates who is sticking with Bing for some reason). Anyhow, the problem with that solution is that you need to schedule the script some how, there are different options available, to schedule a task in Windows or the better alternative where the same stuff is done in Azure.
Well that is exactly the way this solution was configured. And then, ab course something that never happens in the field, customer did had no clue how the solution was set up! Knock knock! No documentation or whatsoever, each time a change needed to be configured, they just used to call up the consultant who performed the changes for them. That was till he left the company he used to work for ab course. Now, it became impossible to get hold of the guy so the company was stuck with old OOF being sent, which were in a desperate need of being updated.
So what do you do when you cannot get hold of the original consultant and you cannot figure out how exactly to solve the problem or where to start? You hire another one. This is how I was engaged in the problem, I was given the task to reconfigure OOF messages that were being sent. I was given Global Admin role to make my life a bit easier though.
Initial troubleshooting showed that some sort of script was being trigged at given time period. After the script was initially triggered, it was retriggered several times. How I know that, I will describe a bit further down the blog post. It was almost like searching for a needle in a haystack, almost impossible, however, it was only “almost” not totally impossible.
One of the guys in IT-Operations who was my contact person told me that he previously had talked with this consultant who used
Set-MailboxAutoReplyConfiguration -Identity firstname.lastname@example.org -StartTime $StartTime -EndTime $EndTime -AutoReplyState Enabled
I was very thankful for the input, but the problem is, this is just the command being executed to set up the OOF, not the routine job that is being executed. So question back to him was, do you know where the job is running or how it is being run? Like is it a service or a service account running a scheduled task? Or is it an Azure scheduled task? Is it a VM in Azure? What is it or what can it be? The response was still, we have no idea!
So the requirement this time from the customer was not only to change the OOF message, but also to make an easy to use and manage solution that they themselves could update if required in the future. Luckily, they had also learned from their mistakes and had put in a requirement to document the entire solution. I immediately thought of using a tool that I have fallen in love with! No, I am not talking about Powershell, at least not this time, I am talking about PowerAutomate. I though it is almost like mobile camera, you just point and shot! There is not need to think about exposure, focus, lighting etc. as the smartphone will take care of most of the stuff any way. So in the same manner, you have the building blocks available in PowerAutomate, you just drag the components you need and then tune them with regards to variable requirements that you might have. This would be the perfect visual tool that the customer can utilize in order to set OOF for Shared mailboxes.
I started off with creating a PowerAutomate flow (workbook). Talking about Flows, you should seriously consider using a naming standard. This holds true for most of the Office 365 products, but is very important especially with tools like PowerAutomate and Microsoft Forms, as the projects you create end up being files in a flat structure. If you have used any of these tools, you know what I mean. Anyhow, back to the reality. I will briefly describe each of the components used in our Flow.
As you can imagine, there are several ways to solve the situation, even in this Flow. You can schedule the job to only run between certain times of between certain time windows, however, then you would have to handle the weekend in some other manner. I therefore chose to just monitor the mailbox, whenever a new mail message arrives. Don’t worry about the performance, trust me this works, without any issues.
So the first thing we do after retrieving the current time is to initialize a number of variables that we are going to use. These include day(dag), Time, IndexColonTime and ActualIndex.
We are going to utilize the day to check if its week days or weekend, time is just to get the time into a formatted variable, Index of colon in time is the position of colon value and actual index tells where to start extraction of data. If you are reading this blog post, I bet you are aware with these terms as these are used in programming languages as well is VB script as well as Powershell.
Now we have checked what time it is and we should now convert it to our time zone, so that we can determine wither or not to do anything with the message, i.e. to respond with an OOF or not.
Now we can start populating variables that we initialized. It will all make sense in a bit.
Here we are extracting days from the converted time zone, we will be getting Mon, Tue, Wed, Thu, Fri, Sat and Sun as possible values based on the formatting you chose in the previous step. This is what I preferred and hence used, but feel free to choose whatever you or your customer needs.
As I am interested in extracting time, I am providing the position of colon. This is what will help me setting the actual indexPosition of actual extraction as done in the next step.
As the picture is omitting some text, I am adding it as code so that it can be copied or viewed for guidance.
Here you can see a couple of substrings being utilized to extract the time. We are not so concerned about minutes and are only interested in hours, as if hours are between 16:00 – 08:00 CET we want to respond to email with an OOF.
Now that the this part has been sorted out, only easy conditions are left, where we leverage the variables that we ourselves had chosen to start off with.
If its weekend, we are interested in sending an OOF. By the way, OOF is Out Of Office message in case you were wondering.
The contents can be whatever you want them to be. Here I am just adding text, but you could also use some fields from a list in Sharepoint that a specific department themselves can update as they want.
On the other hand if its not weekends, we need to check the time we received email.
Now we just cast to hours variable to integer and check for if time is not within 08:00-16:00. If it is not, we can send the OOF and if it is, we do nothing.
Specified object not found in the store
There are a couple of scenarios that might create problems for you, As I initially stated in the beginning of this post, you might even be as lucky as me to encounter Specified object not found in the store! This error and possible resolutions are described at a Microsoft support forum here
However, be sure that the account running the Microsoft PowerAutomate Flow has full access to mailbox that you are intending to monitor and to send OOF.
My specific issue was that I had already tested with another account in this context meaning, another shared mailbox and then just changed the shared mailbox in the Flow. However, this cause the problem as described. So solution to problem was actually to delete the step, save the Flow and then edit it by adding a new step and correctly choosing the shared mailbox. Why it was like this I do not know, but reading through forums I found out the permissions on Shared mailbox was the most common reason. The other reason was that a specific folder was not being located. So, in this step, you can also specify inbox folder, so that this folder is monitored for incoming messages. Wonderful, now we had a working solution. However, the old solution was still causing problems, sending out old messages. So lets see how that was located and removed.
Locating OOF script execution account
I am not a fan of spending a fortune on security products that you end up never using, however, some tools are really worth investing in. If you have Azure Active Directory, it is a must to have access to logs, by logs I mean security and audit logs. Luckily, the customer we are talking about here, was an SMB and more like a MB (Medium business), who had actually invested in proper licenses for the IT department. We were able to find all accounts executing Powershell scripts and finally were able to disable the account which was being utilized to run the scheduled task.
Luckily only a single service account was being used to send OOF, for a couple of shared mailboxes and we were able to change this out. However, if the same account had been used to other tasks as well, we most probably would have ended up in trouble by disable sign-in for this account.
As always, I hope that this blog post helps someone out there, either having trouble with setting up OOF or anyone just receiving this error “object not found in the store”