Richard's Support Ramblings https://docs.microsoft.com/archive/blogs/richardroddy/feed.xml Things I&#039;ve seen as Microsoft Support Escalation Engineer Tue, 24 Jul 2018 21:14:44 GMT en-US hourly 1 User not seeing new emails in OWA, but sees them in Outlook https://docs.microsoft.com/archive/blogs/richardroddy/user-not-seeing-new-emails-in-owa-but-sees-them-in-outlook Tue, 24 Jul 2018 17:12:09 GMT https://blogs.technet.microsoft.com/richardroddy/?p=485 Looking at the screenshot over and over I didn't see it initially, but then I finally spotted the issue: the user has a bunch of messages pinned in OWA. Pinned messages show at the top of the view. If we scroll down beyond the pinned items, I bet we see those "missing" items below the pinned items. Here is an example from OWA for my test mailbox, where I have pinned a bunch of items. Notice the newest item is from 4/4/2018:   Then if I scroll down to where the pins stop I see newer items:   So, scroll down beyond the pinned items, and you should see the "missing" items below those. Once we figured out why the view was as it was, the admin went and explored a bit further with the user and found a rule doing it. The user had erroneously clicked it as part of a rule and ended up pinning all high importance emails.]]> "Stall" attempting to migrate a specific mailbox from Exchange 2013 to Exchange Online https://docs.microsoft.com/archive/blogs/richardroddy/stall-attempting-to-migrate-a-specific-mailbox-from-exchange-2013-to-exchange-online Tue, 24 Jul 2018 16:21:52 GMT https://blogs.technet.microsoft.com/richardroddy/?p=475 The last entry before the failure: 25/05/2018 14:34:38 [EXCHSERVER] Stage: LoadingMessages. Percent complete: 20. And then the failure: 25/05/2018 14:40:40 [EXCHSERVER] Transient error CommunicationErrorTransientException has occurred. To see if we could get some kind of idea of what was going on with the on-premises server at the time, we took a look at the IIS logs from the server and found the error: 2018-05-25 14:40:39 192.168.2.201 POST /EWS/mrsproxy.svc &CorrelationID=<empty>;&ClientId=XXXXXXXXXXXXXXXX&cafeReqId=53ea14e3-cac9-42cb-a82f-a15889e233ae; 443 Domain\SVC_E1_MSXEP 40.100.168.141 - - 500 0 0 61  Http 500 is an "Internal Server Error". So, we have some kind of failure occurring on prem with this mailbox, and the info returned is not able to be interpreted properly when the MRS gets it in Exchange Online, so we get the "generic" 'unexpected end of file' error. We then proceeded to do ExTRA tracing of the MRS component on the On-Prem Exchange server to get a better idea of what was going on there, and what we found was that there was a timeout occurring. The solution here was to go into the C:\Program Files\Microsoft\Exchange Server\V15\Bin folder, and edit the MSExchangeMailboxReplication.exe.config file. Open the file in any text editor (notepad or Notepad++ are fine) and find DataImportTimeout. You should find it under the MRSProxyConfiguration section near the end of the file. We want to change the value from the default of 00:05:00 (5 minutes) to a value in the range to 10-30 minutes (10 minimum). We went with 20 minutes, or "00:20:00" and then saved the change to the file. After the file is saved, we restarted the Microsoft Exchange Mailbox Replication service so that the change takes effect. After that, the mailbox was able to be moved successfully.]]> After enabling Out of Office (Automatic) replies, the replies are not being sent out https://docs.microsoft.com/archive/blogs/richardroddy/after-enabling-out-of-office-automatic-replies-the-replies-are-not-being-sent-out Fri, 06 Apr 2018 09:37:36 GMT https://blogs.technet.microsoft.com/richardroddy/?p=455 As noted in the post title, after enabling Out of Office (Automatic) replies, the replies were not being sent out We found in this case that our issue with the Out Of Office (OOF/Out Of Facitility) not working was due to all of the mailboxes in question having the ForwardingSmtpAddress value set, which is the "Forward my e-mail to" option in the Connected Accounts area in the OWA options/control panel.  We ran the PowerShell command below to clear this value from all of the affected mailboxes: Get-Mailbox | Set-Mailbox -ForwardingSmtpAddress $null Once we cleared this value, the OOF began working.  As a workaround for the forwarding, there are a few options: 1) Create a Transport Rule (in the Mail Control, Rules section of the Exchange Control Panel) and using the Advanced Options, choose to BCC the messages to another recipient. 2) Use the PowerShell command and set the -ForwardingAddress instead of the -ForwardingSmtpAddress Set-Mailbox username -ForwardingAddress address@domain.onmicrosoft.com 3) An Inbox rule can be created to do the forward or redirect: https://help.outlook.com/en-gb/140/ms.exch.ecp.learnredirectto.aspx #1 and #2 will be invisible to the mailbox owner/user #2 actually works a little differently than when ForwardingSmtpAddress is set, and does not break the other auto-replies. After checking these, we found that the OOF still would not work for an admin mailbox that was affected. We found that this was because the admin mailbox is specified as the NDR recipient in the Journaling settings for the organization, which also stops auto-replies and auto-forwards from working, as noted in https://support.microsoft.com/en-us/help/2829319/transport-and-mailbox-rules-in-exchange-online-or-in-on-premises-excha]]> Using PowerShell ISE to connect to Exchange Online when MFA is enabled https://docs.microsoft.com/archive/blogs/richardroddy/using-powershell-ise-to-connect-to-exchange-online-when-mfa-is-enabled Wed, 04 Apr 2018 17:34:18 GMT https://blogs.technet.microsoft.com/richardroddy/?p=415 The customer here wished to be able to use the PowerShell ISE and still be able to connect with MFA (Multi-Factor Authentication) enabled for their account. We already have a PowerShell module designed to allow connection with MFA enabled, but there is no direct integration of it with the PowerShell ISE. When the Microsoft Exchange PowerShell app (https://technet.microsoft.com/en-us/library/mt775114%28v=exchg.160%29.aspx) is installed and executed, it launches a PowerShell session and runs a script to load the necessary modules and functions into the current PowerShell execution to provide the cmdlet. The files related to the app are all loaded into a folder with a path similar to (as this is a Click To Run app): C:\Users\<username>\AppData\Local\Apps\2.0\LC7A9808.VWQ\TDNEY3XY.VWX\micr..tion_c3bce3770c238a49_0010.0000_213d7102fbbdf9ba To find the folder with the files in it, I first went to my Start Menu\Programs folder to find the shortcut for it: C:\Users\<username>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Microsoft Corporation   When I get the properties of that item, I see:   Looking at the Folder path value, I now know the name of the folder the module points to, I can go to the C:\Users\<username>\AppData\Local\Apps\2.0  folder and find the appropriate folder. To successfully use the Connect-EXOPSSession cmdlet in the ISE, I need to "dot load" the CreateExoPSSession.ps1 script found in the above folder into my ISE execution. When it runs, it loads the necessary modules and functions into the session so that the Connect-EXOPSSession cmdlet is available and works to connect to Exchange Online with MFA enabled. This is done with the following syntax after changing to the location of the module: . .\CreateExoPSSession.ps1 Update 4/5/18 - One of my coworkers brought me these 2 lines that we can run, which will find the module for us and load it up in our ISE session, without having to go out and search for it ourselves: $CreateEXOPSSession = (Get-ChildItem -Path $env:userprofile -Filter CreateExoPSSession.ps1 -Recurse -ErrorAction SilentlyContinue -Force | Select -Last 1).DirectoryName . "$CreateEXOPSSession\CreateExoPSSession.ps1"]]> Getting Public Folder Statistics Report in O365/Exchange Online https://docs.microsoft.com/archive/blogs/richardroddy/getting-public-folder-statistics-report-in-o365exchange-online Wed, 04 Apr 2018 17:07:04 GMT https://blogs.technet.microsoft.com/richardroddy/?p=405 In this case, the customer was looking for a way to get the following information from the Public Folders in EXO - this was basically his "wish list" of information that he wanted to get:
  • Folder Display name
  • Folder Path
  • Owner
  • Item Count
  • Last Access Time
  • Last Modification Time
  • Total Item Size
  • Creation Time
  • If it is mail enabled or not
  • email address - if it is mail enabled
 They were able to get this information when the folders were in on-premises Exchange, but  have not been able to find a way to get this since they were migrated to O365.  They wanted the information to use it to clean and remove thousands of unused folders but didn't know a way to get the data. I found a script at https://gallery.technet.microsoft.com/office/Snapshot-report-of-Public-21235573 that was designed to get Public Folder data from Exchange 2010 and returned most of the customer's desired info. It gets everything except for the Last Access info, which is not available in Exchange Online that I can find. I'm supplying the script content as text here, and it can then be copied/paste it into a .ps1 file on the machine you intend to run it on, and it will be trusted, as the .ps1 file is seen as having been created on that machine, and not on some foreign machine. From the original, I had to tweak the syntax to get the PrimarySmtpAddress and to get the list of owners, which I could only retrieve Display Names for. # This Sample Code is provided for the purpose of illustration only and is not intended to be used in a production environment. # THIS SAMPLE CODE AND ANY RELATED INFORMATION ARE PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, # INCLUDING BUT NOT LIMITED TO THE IMPLIED WARRANTIES OF MERCHANTABILITY AND/OR FITNESS FOR A PARTICULAR PURPOSE. # We grant You a nonexclusive, royalty-free right to use and modify the Sample Code and to reproduce and distribute the object # code form of the Sample Code, provided that You agree: (i) to not use Our name, logo, or trademarks to market # Your software product in which the Sample Code is embedded; (ii) to include a valid copyright notice on Your software product # in which the Sample Code is embedded; and (iii) to indemnify, hold harmless, and defend Us and Our suppliers from and against # any claims or lawsuits, including attorneys’ fees, that arise or result from the use or distribution of the Sample Code. Write-Progress -Activity "Finding Public Folders" -Status "running get-publicfolders -recurse" $folders = get-publicfolder -recurse -resultsize unlimited $arFolderData = @() $totalfolders = $folders.count $i = 1 foreach ($folder in $folders) { $statusstring = "$i of $totalfolders" write-Progress -Activity "Gathering Public Folder Information" -Status $statusstring -PercentComplete ($i/$totalfolders*100) $folderstats = get-publicfolderstatistics $folder.identity $folderdata = new-object Object $folderdata | add-member -type NoteProperty -name FolderName $folder.name $folderdata | add-member -type NoteProperty -name FolderPath $folder.identity $folderdata | add-member -type NoteProperty -name LastAccessed $folderstats.LastAccessTime $folderdata | add-member -type NoteProperty -name LastModified $folderstats.LastModificationTime $folderdata | add-member -type NoteProperty -name Created $folderstats.CreationTime $folderdata | add-member -type NoteProperty -name ItemCount $folderstats.ItemCount $folderdata | add-member -type NoteProperty -name Size $folderstats.TotalItemSize $folderdata | Add-Member -type NoteProperty -Name Mailenabled $folder.mailenabled if ($folder.mailenabled) { #since there is no guarentee that a public folder has a unique name we need to compare the PF's entry ID to the recipient objects external email address $entryid = $folder.entryid.tostring().substring(76,12) # $primaryemail = (get-recipient -filter "recipienttype -eq 'PublicFolder'" -resultsize unlimited) | where {$_.externalemailaddress -like "*$entryid"}).primarysmtpaddress $primaryemail = (get-recipient $folder.mailrecipientguid.tostring()).primarysmtpaddress $folderdata | add-member -type NoteProperty -name PrimaryEmailAddress $primaryemail } else { $folderdata | add-member -type NoteProperty -name PrimaryEmailAddress "Not Mail Enabled" } if ($folderstats.ownercount -gt 0) { $owners = get-publicfolderclientpermission $folder.identity | where {$_.accessrights -like "*owner*"} $ownerstr = "" foreach ($owner in $owners) { $ownerstr += $owner.user.displayname + "," } } else { $ownerstr = "" } $folderdata | add-member -type NoteProperty -name Owners $ownerstr $arFolderData += $folderdata $i++ } $arFolderData | export-csv -path PublicFolderData.csv -notypeinformation ]]> User failing to migrate with "Server returned an invalid SOAP Fault - unexpected end of file" https://docs.microsoft.com/archive/blogs/richardroddy/user-failing-to-migrate-with-server-returned-an-invalid-soap-fault-unexpected-end-of-file Tue, 24 Oct 2017 18:11:43 GMT https://blogs.technet.microsoft.com/richardroddy/?p=396 Archive policy not moving emails from main mailbox to archive https://docs.microsoft.com/archive/blogs/richardroddy/archive-policy-not-moving-emails-from-main-mailbox-to-archive Tue, 24 Oct 2017 17:21:31 GMT https://blogs.technet.microsoft.com/richardroddy/?p=386 Use MFC Mapi and go to Root Container -> Finder and open the folder NoArchiveTagSearchFolder... When you open the folder it should show all items that do not have an archive tag - these are the items that MRM would process based on the default tag. Sort by Receive date. Are there any items that should expire? If the folder does not exist, then MRM may not be recognizing the default archive tag. The folder did exist here, but there were no items showing up in it, even though there were plenty of items. We deleted the search folder with MFCMAPI, and then ran the following command in PowerShell connected to Exchange Online (https://technet.microsoft.com/en-us/library/jj984289(v=exchg.160).aspx): Start-ManagedFolderAssistant username After this, items started moving to the archive as expected. We also could check with MFCMAPI and see the search folder now showed items that should move to archive, but had not yet moved.]]> Using an Exchange Transport Rule to reject messages sent to a specific domain with a custom NDR https://docs.microsoft.com/archive/blogs/richardroddy/using-a-transport-rule-to-reject-message-sent-to-a-specific-domain-with-a-custom-ndr Tue, 24 Oct 2017 16:24:50 GMT https://blogs.technet.microsoft.com/richardroddy/?p=385 tailspintoys.org. This seems to be because when we check the recipient in Exchange for the rule condition, we only see the recipient's primary SMTP address. The solution I found is that creating a new rule with “Create a new rule” and then clicking “More options”, I used the following condition: - Apply this rule if… A message header includes: 'authentication-results' header includes 'tailspintoys.org' - Do the following Reject the message with the explanation: 'sorry this domain has been decommissioned, please try your contact's address with @contoso.org' This works because the authentication-results header always contains the domain that the message was sent to. I can’t take full credit for this solution, as I found it in a post or old support case (can’t remember which) I looked at as I was searching for answers.    ]]> Account is not a member of Enterprise Admins group when configuring AD Connect https://docs.microsoft.com/archive/blogs/richardroddy/account-is-not-a-member-of-enterprise-admins-group-when-configuring-ad-connect Fri, 12 Aug 2016 17:53:54 GMT https://blogs.technet.microsoft.com/richardroddy/?p=375 Meetings Disappearing From Exchange 2003 Resource/Room Mailboxes https://docs.microsoft.com/archive/blogs/richardroddy/meetings-disappearing-from-exchange-2003-resourceroom-mailboxes Mon, 08 Aug 2011 15:11:37 GMT https://blogs.technet.microsoft.com/richardroddy/2011/08/08/meetings-disappearing-from-exchange-2003-resourceroom-mailboxes/ In this case, I was presented with the symptom of meetings disappearing from a Resource mailbox in Exchange 2003 that had been set up for automatic booking with the Exchange 2003 Auto Accept Agent.

After going round and round with the customer to try and get good tracing information from the server, we finally got a good store trace of the behavior.

What was found was that there was a Delegate defined on the Resource Mailbox. Mixing delegates with the Auto Accept Agent can potentially end up causing issues if we're not sure to take precautions. This was the case here.

Note this excerpt from the Auto Accept Agent Deployment and Administration Guide, Managing Resource Mailboxes topic (https://technet.microsoft.com/en-us/library/bb124314(EXCHG.65).aspx):

Modifying Delegate Settings:

You can add delegates to a resource mailbox who can then access the mailbox directly to check existing appointments, check mail in the Inbox, or processed requests in the Sent Items folder. However, if you allow delegates to receive copies of meeting requests sent to a resource mailbox, it is possible that the delegate may accept a meeting request even though the agent has declined the meeting. To avoid this situation, it is recommended that you do not allow delegates to receive copies of meeting requests. You must open the resource mailbox as the primary mailbox to modify delegate settings. You cannot modify delegate settings if the resource mailbox is a secondary mailbox.

To prevent delegates from receiving copies of meeting requests:
1. In Outlook 2003, click Tools and then click Options.
2. On the Delegates tab, select a delegate, and then click Permissions.
3. Clear the check box for Delegate receives copies of meeting-related messages sent to me.

What I saw in our store traces, is that for the problems, the delegates were causing modifications to the calendar. What was likely happening is that the delegate was deleting the copy of the meeting invitation they received, and this in turn was deleting the meeting from the calendar.

We then found that the resource mailbox was indeed set to forward the meeting request copies to the delegates and turned that option off.

After this there was a thought by one user that a meeting disappeared, but additional logging and investigation showed that meeting to have been one that was removed prior to the change in the setting.

]]>