This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(38.4, 84%, 13%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ECH%3C/text%3E%3C/svg%3E)
We just noticed that all of our Exchange 2016 servers (running on Win 2012 R2) will no longer launch as administrator.
When we right click the EMS and select "run as adminstrator", the shell window opens up as "Administrator: Serveraname.domainname but, when the 2nd "Verbose: Connected to Servername.domainname" appears, the shell goes to "Machine: Servername.domainname"
We discovered this when we tried to run a command "Get-Inboxrule" and it said the mailbox did not exist, which it does.
We had 2 things happen this past weekend - 1st, we updated our external certificate and 2nd, we installed CU18 over the weekend. We checked the new cert and it's assigned to SMTP, IIS, IMAP, POP on all exchange servers. I didn't think the EMS was tied to an external cert, only the Exchange certificate (Which does not expire until late next year)
Anyone heard of any issues with CU18 causing this issue? We have 1 issue with CU18, users who log into OWA to access a shared mailbox can no longer download a file (it points to O365, and we are not setup for Hybrid), so we are waiting for the next CU release to fix that issue (we have a work around until then).
Thoughts?
Machine: Servername.domainname"
that sounds normal actually.
Does the account have the correct Exchange permissions?
Get-Inboxrule will fail for all mailboxes except for account running the command. IOW, you can only view your own settings if you do not have the correct perms to view all mailboxes.
Have you tried with other commands?
Glad to hear I was not imaging things on the Administrator vs Machine window.
To answer your questions: Yes, the user account being used does have the correct exchange permissions, been using the same account for the past year without issue.
Before the certificate update and the CU 18 install, I was able to run the get-inboxrule against my mailbox without issue. I have Inbox rules just to make sure i get results with the command.
I can run the command Get-Mailbox against a mailbox, and we get output: Name, Alias, ServerName, ProhibitSendQuota.
When trying to run the Get-InboxRule command against the same mailbox we get:
"The operation couldn't be performed because "UserMailbox" couldn't be found"
We ran this scenario locally on a couple of our exchange servers and all of them produce the same result.
Also, I checked the bindings on the Exchange servers, we are using the self-signed Microsoft Exchange certificate for the Exchange Back End within IIS manager:
That looks good!
So how about if you run Exchange powershell from a workstation instead? Same problem?
https://learn.microsoft.com/en-us/powershell/exchange/connect-to-exchange-servers-using-remote-powershell?view=exchange-ps
Yes, same issue when trying to run a remote ps session from a workstation or jump server.
Funny thing is, the command worked before, as I was able to output the results to a csv file.
I just tried piping the Get-mailbox command and it worked: Get-mailbox "userid" | Get-InboxRule | FL Name .....and we get the list of rules
But trying just the Get-InboxRule "userid" | FL Name ..... We get the error "The operation couldn't be perfromed because "mailbox" couldn't be found".
See Erics answer below, sure you arent just using the wrong syntax?
Just a follow up and close this out, Thanks to @Andy David - MVP and @Eric Yin-MSFT for throwing this dog a bone and forcing this old dog to looking into our script issue more closely.
When it came down to it, I have no idea how the script was working that our 3rd level team was using. :(
The script was receiving the userid as the the 1st parameter to Get-Inboxrule, which in this case is "-Identity". How this was working before, I have no idea. Reviewing the documentation on Get-Inboxrule, -Identity is the NAME of the RULE someone wants to review, NOT the Users mailbox. I change the script to accept the userID to the parameter "-Mailbox" and 3rd level support has not had an issue since.
Also, the ticket we have open with MS on the OWA/Shared MB/Preview/Download issue, a CU will be coming soon to fix that issue. I believe they are targeting dec/2020 release for a CU release.
Thanks
Cool. Glad it working!
IF you could, mark an accepted answer so this can be closed. I think Eric's answer fits that bill!
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(28.799999999999997, 82%, 12%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EEY%3C/text%3E%3C/svg%3E)
First you have to know "get-inboxrule user1" means "get-inboxrule -identity user1".
Then I just wonder if you have confused the parameter "-indentity" with "-mailbox":
See Get-inboxrule.
If an Answer is helpful, please click "Accept Answer" and upvote it.
Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.
Good catch!
Hi Eric,
Yes, I realize the format required for the get-inbox rule and we have been using the userid as the identity and not the mailbox identity. We have been using this command on a regular basis it seems and since the CU update, it no longer works as it's suppose to. I posted here to see if any other Exchange 2016 administrators are having the same issue with this command after installing the CU 18 update.
I do have a support ticket open with MS concerning CU18 and attachment view/download issues via OWA and a shared mailbox. I will see if the support person will ask about this possible issue as well.
Thanks for clarifying the variables required for this particular exchange powershell command.
Hi,
I just test it on my Exchange 2016 CU17 and got same results:
The attachement issue should be fixed in next CU, you can refer to this thread for a workround. No need to open a ticket for this.
If an Answer is helpful, please click "Accept Answer" and upvote it.
Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.