Jeremy Knight https://docs.microsoft.com/archive/blogs/jeremyknight/feed.xml Office 365 - Exchange Online Tue, 16 Apr 2019 06:10:35 GMT en-US hourly 1 Exchange Online Fiddler Extension 1.0.63 https://docs.microsoft.com/archive/blogs/jeremyknight/exchange-online-fiddler-extension-1-0-63 Fri, 14 Dec 2018 22:48:43 GMT https://blogs.technet.microsoft.com/jeremyknight/?p=675
  • Sessions are colourised per session rule set.
  • Only the Host IP column is enabled, since this is build from an already existing session flag.
  • High cost compute logic does not run.
  • Inspector tabs do not build controls, instead they show instructions to save the Fiddler trace as a SAZ archive, close Fiddler and reopen for full extension functionality.
    • To get the extension full functionality simply open a SAZ file previously captured. This will light up all custom columns, all session logic and the inspector tabs with all controls for troubleshooting.]]>         Exchange Online Fiddler Extension 1.0.60 https://docs.microsoft.com/archive/blogs/jeremyknight/exchange-online-fiddler-extension-1-0-60 Fri, 07 Dec 2018 20:28:37 GMT https://blogs.technet.microsoft.com/jeremyknight/?p=625 https://github.com/jprknight/EXOFiddlerExtension/releases This version adds significant functionality in the authentication space.
    • An authentication column has been added giving key information on which sessions contain authentication headers / data.
    • An 'Office365 Auth' inspector tab has been added showing more detailed information on authentication.
    • SAML response parser in the 'Office365 Auth' tab. See the SAML responses, see the signing certificate.
    Screenshots showing what this release brings. New Authentication column: 'Office365 Auth' inspector tab, generally you will see this view apart from... ...when you highlight a SAML request/response session. Then you will see the below where you can confirm SAML token issuer, responses which include the UserPrincipalName and ImmutableID, and open the signing certificate. ]]>         Exchange Online Fiddler Extension 1.0.50 https://docs.microsoft.com/archive/blogs/jeremyknight/exchange-online-fiddler-extension-1-0-50 Wed, 21 Nov 2018 07:46:36 GMT https://blogs.technet.microsoft.com/jeremyknight/?p=475 https://blogs.technet.microsoft.com/jeremyknight/2018/10/01/introducing-the-exchange-online-fiddler-extension/ we have now made significant improvements to the extension and have just made version 1.0.50 available. Improvements in this new version include:
    • Performance troubleshooting enhancements to the inspector tab. -- See how long the Exchange Online server took to respond to requests.
    • Updates to the rule set, new scenarios for highlighting / providing information on scenarios we have seen in support cases.
    • Expanded out the menu to include more options, making it easier to use.
    • Added X-HostIP column. Easier to see local vs. internet IP responding server / device.
    • Title of the 'Exchange Online' menu will now show if an update is available.
    • Minimal telemetry data collected for usage statistics.
    The update is available now at: https://github.com/jprknight/EXOFiddlerExtension/releases. For any questions see: https://github.com/jprknight/EXOFiddlerExtension/wiki. For any issues see: https://github.com/jprknight/EXOFiddlerExtension/issues. Happy troubleshooting!]]>         Introducing the Exchange Online Fiddler Extension https://docs.microsoft.com/archive/blogs/jeremyknight/introducing-the-exchange-online-fiddler-extension Mon, 01 Oct 2018 22:34:08 GMT https://blogs.technet.microsoft.com/jeremyknight/?p=335 The Support and Recovery Assistant (SARA), particularly useful to detect client based issues is the Collect Information about my Outlook configuration option in SARA, Outlook ETL files (can only be viewed by Microsoft support), and Fiddler traces to see the conversation between the Outlook client and the server - Exchange Online / Office 365 / Authentication or Federation provider. This post is about the Exchange Online Fiddler Extension which enhances the Fiddler UI to make troubleshooting Outlook connectivity with Exchange Online easier and more efficient. If you already know what this is then you are probably just looking for the download link: https://github.com/jprknight/EXOFiddlerExtension/releases. Or the wiki page: https://github.com/jprknight/EXOFiddlerExtension/wiki Or for questions, issues or suggestions: https://github.com/jprknight/EXOFiddlerExtension/issues

    What does the extension do?

    • Colourise sessions.
    • Additional columns added to UI.
      • Elapsed time -- Shown when loading a SAZ file if enabled.
      • Response server -- The type of web server which responded to the request.
      • Exchange Type -- This is a field populated from logic checks based on request and response values. This will contain the client used, type of connection, or process if not related to Exchange or Outlook.
      • X-HostIP -- This is the IP address of the responding host. It can be very useful to know if the responding server is on the LAN vs. the internet.
    • Inspector tab added to the UI.
      • The extension adds an Exchange Online tab to the response inspector list.
      • This tab brings together useful information for troubleshooting issues.
      • Expect to see information from the sessions along with logic based comments in the response comments box.
    • Application Logging.
      • Logs the logic checks the extension finds on sessions into the Fiddler application log for viewing.
      • Go to the logging tab to see all the events recorded on all sessions.
    • Update Checking.
      • The extension checks for available updates, so you don't get left behind running an old version.
      • From v1.0.50 the Exchange Online menu will update it's title to give you a visual cue an update is available. -- See the menu screenshot at the bottom of this post.
    • Menu added to the UI to control the extension.
      • Extension Enabled -- Running the extension with all options turned on involves a performance cost. You can turn off the extension if not currently using it. This will stop all session logic processing, the expensive compute cost of running the extension.
      • Columns enable/disable.
      • Application Logging Enabled -- Enable/disable switch for the application logging.
      • Extension Wiki -- Link out to the project Wiki.
      • Report Issues -- Link out to the project issues page.
      • Check for updates -- Extension checks against updates. Note: Set the options you want on the menu and restart Fiddler for changes to take effect.

    What kind of scenarios can the extension help me troubleshoot?

    • Authentication:
      • ADFS or third-party federation provider is unreachable or unavailable. No authentication tokens generated for users as they request them means no access to Office 365 resources.
      • Outlook throwing unexpected authentication prompts.
    • Autodiscover:
      • Autodiscover not responding or responding with incorrect information.
      • An Autodiscover response from a non-Exchange server.
    • Network Connectivity:
      • Web proxy or other device blocking Outlook traffic from reaching the internet and Office 365 / Exchange Online.
      • Outlook cannot connect to an Exchange Online mailbox.
      • Outlook cannot communicate with an Exchange server - either On-Premise or in Exchange Online.
    • Performance troubleshooting:
      • Check the length of time sessions take to complete.
      • Check the length of time the Exchange Online server took to service the request 'Server Think Time'.
      • Check the length of time it took to send the response back to Fiddler and for Fiddler to relay the response back to the client app (Outlook).
    • Others:
      • OWA cannot connect to an Exchange Online mailbox.
      • Outlook or OWA cannot perform a specific function with the mailbox.
      • Exchange Free/Busy and other EWS calls.

    What does it look like?

    Colourisation of sessions and additional columns

    Prior to installing and enabling the extension all sessions would be shown in white. The extension is using logic to detect the severity of session responses and highlight what we need to focus on for troubleshooting. See the Extension Colour Code Explanation wiki page for more details on what these colours mean. In this lab sample a squid proxy has been installed which is set to block all traffic for outlook.office365.com. Client computers in the environment are set to route all internet traffic through the proxy server. The result is Outlook cannot connect to the Exchange Online mailbox and HTTP 403 responses are seen from the web proxy server on the disallowed traffic. Notice the addition of the Elapsed Time, Response Server, Exchange Type, and X-HostIP columns. Update (10/15/2018): Exchange Type is now louder about any specific scenario found, shown in the screenshots below. Look for anything in Exchange Type in capital letters enclosed in exclamation marks. For example: !FEDERATION! or !WEB PROXY BLOCK! Highlight on HTTP 403, sessions are being blocked by a web proxy server. This HTTP 503 Service Unavailable was simulated in a lab by taking the 'Active Directory Federation Services' service offline on the Web Application Proxy server.

    Inspector Tab

    HTTP 200's: Not all 200 OK server responses are actually OK. Some contain an error, failure or exception response. Unless a specific scenario is detected for HTTP 200 OK responses the extension is splitting each word in the response body and looking for 'error', 'failed', or 'exception'. If found the session will be highlighted with red text on a black background in the session list, the Exchange Type will show !FAILURE LURKING!

    A HTTP 200 OK server response which is actually OK.

    In this however, the HTTP 200 is an Autodiscover response from Exchange On-Premise server with a redirect address (you may know this as the target address or remote routing address). The response is exactly what we want in this scenario so this session is coloured green in the session list.

    HTTP 403 Forbidden

    This HTTP 403 Forbidden accompanies the session colourisation scenario above. This is one of the HTTP 403 responses from that trace. The tell in this scenario is the response server is squid/3.5.27, which is configured to block Outlook's traffic for outlook.office365.com. This session is highlighted as red in the session list. This could just as easily be another brand of web proxy server showing up in the same scenario, squid just happens to be an easy way to reproduce this behaviour in a lab environment.

    HTTP 503 Service Unavailable

    This HTTP 503 Service Unavailable was simulated in a lab by taking the 'Active Directory Federation Services' service offline on the Web Application Proxy server. This means when the Outlook client hits the realm page for basic authentication (shown below), Exchange Online takes over and attempts to authenticate on behalf of the user to the federation service, it is offline and cannot service the authentication request. At this point Outlook most likely prompts for credentials which cannot be satisfied, and cannot connect to the Exchange Online mailbox.

    Menu to control the extension

    From v1.0.50 of the extension the menu will now give you a visual cue if there is an update available. Use the 'Check for update' menu option or visit https://github.com/jprknight/EXOFiddlerExtension/releases to download the update. Here's hoping this extension helps you troubleshoot an Outlook or Exchange issue. Further information can be found here: https://github.com/jprknight/EXOFiddlerExtension/wiki Any queries, issues or questions can be posted here: https://github.com/jprknight/EXOFiddlerExtension/issues. Happy troubleshooting!]]>         Troubleshooting Users: Script to pull all user data https://docs.microsoft.com/archive/blogs/jeremyknight/troubleshooting-users-script-to-pull-all-user-data Thu, 05 Jul 2018 22:53:16 GMT https://blogs.technet.microsoft.com/jeremyknight/?p=275 I have worked a number of support cases where this script has been useful for pulling just about any data available from a user object. Ideally you will want to run this from a PowerShell window connected to both Microsoft Online and Exchange Online PowerShell modules. This script prompts for the User Principal Name of the account to run against, it then works to run a series of Get- cmdlets. Everything is written out to a file for review. See https://gallery.technet.microsoft.com/Troubleshooting-a-user-88f65f15 for a description and to download the script.]]> Troubleshooting Retention: Script to pull user policy and tags https://docs.microsoft.com/archive/blogs/jeremyknight/troubleshooting-retention-script-to-pull-user-policy-and-tags Thu, 05 Jul 2018 22:51:35 GMT https://blogs.technet.microsoft.com/jeremyknight/?p=265 https://gallery.technet.microsoft.com/Troubleshooting-Retention-1eeb55af?redir=0 for the script description and to download.]]> Fiddler capturing and decrypting traffic on a different network https://docs.microsoft.com/archive/blogs/jeremyknight/fiddler-capturing-and-decrypting-traffic-on-a-different-network Fri, 11 May 2018 19:24:06 GMT https://blogs.technet.microsoft.com/jeremyknight/?p=165 Prerequisites
    1. You need a Windows client machine with a public IP address. I want to capture from different machines on different networks.
    2. Install Fiddler.
    3. Add an inbound firewall rule for client devices to connect to port the Fidder proxy is running on. For example, in my case I added an inbound firewall rule to allow 9988.
    4. Make sure both 'Capture HTTPS CONNECTs' and 'Decrypt HTTPS traffic' are selected in Fiddler under the Tools menu, Options, HTTPS tab.
    5. Set your Fiddler listening port to match your inbound firewall rule. Go to the Connections tab, change the port Fiddler listens on to something less standard than 8080 or 8888, then check the 'Allow remote computers to connect' option.

    The Fiddler secret sauce

    This part had my mind running in circles for a couple of days. Eventually I spoke to my colleague Jason for some guidance. He's a big fan of Fiddler, even he does not think this method has been documented before now.
    1. Per the above you should by now have Fiddler capturing and decrypting traffic on the local computer.
    2. However to make sure Fiddler is capturing traffic, open a web browser and go to google.com on the computer you have Fiddler running on, you should see the traffic captured in the tool. You should also see 'Capturing' in the bottom left hand corner of the tool.
    3. Clear all sessions to make the next steps easier.
    4. On your Fiddler computer open a web browser and go to https://localhost:9988 or what ever port number you set in step 5 above.
    5. We are expecting to see the 'Fiddler Echo Service' web page. If you do not, check the prerequisites section or post comments below.
    6. Download the FiddlerRoot certificate, save it, it does not matter where. We are not going to use the saved file, we are in fact going to use the Fiddler certificate, captured by Fiddler to serve up to client devices.
    7. Stop capturing. Notice we do not enable this again, we do not need to capture any more local traffic.
    8. Back in fiddler select all frames on the left hand side, then CTRL click the two frames shown below in Fig 1 to deselect those frames. Everything else is just noise, including the favicon. Remove the selected sessions.
    9. We want to only see the two frames shown below in Fig 1.
    10. You now want to click on the AutoResponder tab shown below in Fig 1.
    11. Drag and drop the two frames from the left panel to the right panel.
    12. This creates two rules for the AutoResponder.
    13. Ensure you check both 'Enable rules' and 'Unmatched requests passthrough'.
    14. Look towards the bottom of the rule list and you will see rule editor.
    15. Your rules will currently say 'EXACT:https://localhost:9988/' for example.
    16. You need to edit these so they resemble the rules in Fig 1 below. In my example the rules are changed to ':9988/' and ':9988/FiddlerRoot.cer'. Without those quotation marks!
    17. Make sure to click Save on the bottom right as you edit each rule.
    18. Optional/Additional: On my remote client machine (actually another Windows computer) with or without proxy settings setup to direct web traffic to my Fiddler proxy, I can now load the Fiddler Echo Service page. However I found I could not download the certificate. This was fixed by 'Promoting' the FiddlerRoot.cer rule above the :9988/ rule. Right click on the Fiddler.cer rule and click Promote.
    19. Update: I reran through this whole doc on a new VM to validate the instructions and I needed to do this a second time around as well.
    Fig. 1

    End state notes

    1. I have a Fiddler Echo Service page which loads for any client on the internet, regardless of whether the machine / device is sending web traffic to the Fiddler proxy already or not.
    2. Clients need to download the certificate from this service page, install it and trust it, so the Fiddler proxy can decrypt the traffic without web services throwing certificate warnings.
    3. I can have mobile devices (iOS/Android), Windows or any other device for that matter route traffic through this proxy, so the requests/responses can be captured and reviewed for troubleshooting.
    4. Typically this setup is going to be used for in-house repro's of customer issues. This is not a web proxy for any kind of production use.
    5. Why did we remove the EXACT:https://localhost from the rules? We need to allow any host using whatever host name they like to connect to the service. The rule with localhost would only allow the computer running Fiddler to connect.
    6. A note on security: Should you leave Fiddler running on your internet connected Windows VM? No you should not. We only want this service online when we need it to troubleshoot. Simply make sure the Fiddler application is closed. Run a netstat -ano | find "9988" to validate the port is no longer listening if you like. Better still if you are running this in Azure like me, shut the VM down and save some pennies. Job done.
         ]]>         Office 365 Dynamic Distribution Groups Filtered by On-Premise Organization Unit (OU). https://docs.microsoft.com/archive/blogs/jeremyknight/office-365-dynamic-distribution-groups-filtered-by-on-premise-organization-unit-ou Thu, 22 Jun 2017 20:03:44 GMT https://blogs.technet.microsoft.com/jeremyknight/?p=36 First and foremost, update your AADConnect version! See https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-version-history. August 2018 update

    Steps to create the rule

    From the AADConnect server click start, and type sync you should see the 'Synchronization Rules Editor'. We will use this tool to create the rules. Click add new rule, complete the first page as below. Pay close attention to these settings, Link Type for example defaults to Provision which is incorrect this in scenario.   Scoping filters left blank. Join rules also left blank. The real work happens under Transformations. In the first expression I am synchronising the full Distinguished Name from On-Premise AD to extensionAttribute10. This is customAttribute10 in Exchange Online.

    CStr([dn])

    In the second expression I am synchronising the 2nd component in the Distinguished Name from On-Premise to extensionAttribute11. This is customAttribute11 in Exchange Online.

    DNComponent(CRef([dn]),2)

    Need something else maybe? Use https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnectsync-functions-reference. There is no need to do both, I am just showing the possibilities. Perhaps you only need the the second expression example to create your DDG.

    My observations after making these changes

    After changes to the rules, the new values are not seen in the custom attributes until:
    1. A value on the individual object is updated and a delta sync runs or
    2. An initial sync is run.
    So make sure to run a full sync after creating a rule. Start-ADSyncSyncCycle -PolicyType initial Once an initial sync is run after the rule creation, delta syncs send updates to the OU path just fine. Results on a sample Exchange Online object: I am now ready to setup a Dynamic Distribution group based off of CustomAttribute11 with a value of 'nintendo'. I put the full OU in CustomAttribute10 in case there is a use case out there where this is needed. I tested all this by creating a Dynamic Distribution Group with an additional rule of customAttribute11 as 'nintendo', note my deliberate omission of the capitalisation just for the sake of testing if this is important, it is not. Sent an email to the SMTP address of the DDG and confirmed mail delivery to the individuals in the DDG. Perfect! August 2018 Update Since first writing this blog article a little over a year ago I have completely rebuilt my lab environment and did not set this configuration back up. I now have a lab with over 75,000 sync'ed objects so have good basis to test this again. I ran through the steps as originally documented with no issues. As I previously noted only objects which have attributes updated post changes will have the On-Premise OU attributes updated / sync'ed to the cloud on the next delta sync. I tested this out by updating several address type fields on a single account and running a delta sync. Only the object I updated out of ~77,000 objects updated in the delta sync. From this test I can confirm the necessity to run an initial sync so all sync'ed objects get the On-Premise OU sync'ed to custom attributes in the cloud. You then have a consistent data set in the cloud to create Dynamic Distribution Groups from. Running an initial sync after these changes on slightly over 75,000 objects took just under 4 hours to complete in my lab environment.]]>         Exchange Online Cross Tenant Calendar Free/Busy Availability Information https://docs.microsoft.com/archive/blogs/jeremyknight/exchange-online-cross-tenant-calendar-freebusy-availability-information Sat, 27 Feb 2016 00:06:17 GMT https://blogs.technet.microsoft.com/jeremyknight/?p=23 The following steps below need to run in each tenant, as each tenant creates a one-way Organization Relationship to the other tenant. Step 1: First we will enable organization customization, lighting up the features. 
    Enable-OrganizationCustomization
    Step 2: We then need to create an Organization Relationship, lighting up the configuration. Since both organizations in my scenario are in Exchange Online it is important to note the use of the .onmicrosoft.com in the -DomainName parameter. You will see the result in the TargetAutoDiscoverEpr attribute once the Organization Relationship is created; it should look like this: 
    TargetAutodiscoverEpr : https://autodiscover-s.outlook.com/autodiscover/autodiscover.svc/WSSecurity
    Anyway back to creating that Organization Relationship. Let's say you are running the below Powershell command in tenant A, your -DomainName parameter will point to tenantB.onmicrosoft.com, similiarly you will probably want the name to be more in line with your organizational names. 
    Get-FederationInformation -DomainName contoso.onmicrosoft.com | New-OrganizationRelationship -Name "Organization Relationship with contoso.com" -FreeBusyAccessEnabled $true -FreeBusyAccessLevel AvailabilityOnly
    Notice the AvailabilityOnly on that last command? Check out https://technet.microsoft.com/en-us/library/ee332357(v=exchg.160).aspx. If you want your users to see more information, you could choose to use -LimitedDetails so your users can see 'Free/busy access with time, subject, and location'. Step 3: Now our Organization Relationship is in place, we should check a couple of things, which will prevent us from tripping up as we test the configuration with Outlook and OWA. Run the below (and copy the result to notepad to refer to as you go through the rest of these steps): 
    Get-OrganizationRelationship "Organization Relationship with contoso.com" | FL
    In this scenario both organizations are in the cloud, so confirm the TargetAutodiscoverEpr is set as below: 
    TargetAutodiscoverEpr : https://autodiscover-s.outlook.com/autodiscover/autodiscover.svc/WSSecurity
    Potentially it can look like the below (pointing to an On-Premise Exchange environment): 
    TargetAutodiscoverEpr : https://autodiscover.contoso.com/autodiscover/autodiscover.svc/WSSecurity
    If it is, you must have used -DomainName contoso.com instead of -DomainName -contoso.onmicrosoft.com when you ran the command to create the Organization Relationship. You can simply run the below command to remove the Organization Relationship, and start again from step 2. 
    Get-OrganizationRelationship "Organization Relationship with contoso.com" | Remove-OrganizationRelationship
    Getting back on track, when we created the Organization Relationship, we used the -DomainName contoso.onmicrosoft.com we need to add the vanity domain into the configuration, so as Free / Busy requests come in the tenant knows which Organization Relationship to use. To do this we run: 
    Get-OrganizationRelationship "Organization Relationship with contoso.com" | Set-OrganizationRelationship -DomainNames contoso.mail.onmicrosoft.com, contoso.onmicrosoft.com, contoso.com
    Note in the example above we are adding contoso.com, the vanity domain name to the Organization Relationship. Step 4: Testing. At this point we are done, we may just have to wait for Azure Active Directory replication. We can now test the functionality in Outlook and OWA clients and see what results we get. With everything we have done above users can check cross tenant availability information using email addresses, you will need to create mail contacts in order for users to be able to search and select the other tenants contacts from the address book; Though this is another topic for another day.  ]]>         Hybrid Configuration Wizard - DataStrings.InvalidSmtpDomainName(domain) error connecting to On-Premise Exchange https://docs.microsoft.com/archive/blogs/jeremyknight/hybrid-configuration-wizard-datastrings-invalidsmtpdomainname-error-connecting-to-on-premise-exchange Mon, 08 Feb 2016 21:02:18 GMT https://blogs.technet.microsoft.com/jeremyknight/?p=21 https://support.microsoft.com/en-us/kb/3132123 so any future occurrences of this issue can be quickly resolved. The article contains the in-depth steps needed to remove the configuration for the (decommissioned) On-Premise Exchange server.]]>