starred/Set-OutlookSignatures-Set-OutlookSignatures

Fork 0

mirror of https://github.com/Set-OutlookSignatures/Set-OutlookSignatures.git synced 2026-04-26 10:45:52 +03:00

[GH-ISSUE #111] Script hanging at Connect to Outlook Web #48

New issue

Closed

opened 2026-02-27 20:30:59 +03:00 by kerem · 4 comments

kerem commented

2026-02-27 20:30:59 +03:00

Owner

Originally created by @stipman on GitHub (May 2, 2024).
Original GitHub issue: https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/issues/111

Originally assigned to: @stipman on GitHub.

Working to deploy corporate signatures and the script is hanging when attempting to connect to outlook web. (output snip below)
The only thing I can do is ctrl-c and quit the script. Can you tell me why this might be happening?
...
Process mailbox specific templates @2024-05-02T15:25:32-04:00@
'VariablesTest.docx' (Signature ini index #3) @2024-05-02T15:25:32-04:00@
Check permissions
Allows
No email address match for current mailbox, checking current user specific allows
Email address: Mailbox and current user do not have any allowed email address
Do not use template as there is no allow or at least one deny
Process replacementvariable specific templates @2024-05-02T15:25:32-04:00@
Set up environment for connection to Outlook Web @2024-05-02T15:25:32-04:00@
Connect to Outlook Web
...

Using the following options when starting the script (I have replaced actual fileserver name and share)

& '\fileserver\share\OutlookSignatureTemplate\set-outlooksignatures.ps1' -SignatureTemplatePath "\\fileserver\share\OutlookSignatureTemplate\DOCX"
-SignatureIniPath '\fileserver\share\OutlookSignatureTemplate\Config_Signatures.ini' -OOFTemplatePath "\\fileserver\share\OutlookSignatureTemplate\OOF"
-OOFIniPath '\fileserver\share\OutlookSignatureTemplate\Config_OOF.ini' -GraphConfigFile '\\fileserver\share\OutlookSignatureTemplate\Config\GraphConfig.ps1'
-GraphOnly $false `
-ReplacementVariableConfigFile '\fileserver\share\OutlookSignatureTemplate\Config\ReplacementVars.ps1'

Originally created by @stipman on GitHub (May 2, 2024). Original GitHub issue: https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/issues/111 Originally assigned to: @stipman on GitHub. Working to deploy corporate signatures and the script is hanging when attempting to connect to outlook web. (output snip below) The only thing I can do is ctrl-c and quit the script. Can you tell me why this might be happening? ... Process mailbox specific templates @2024-05-02T15:25:32-04:00@ 'VariablesTest.docx' (Signature ini index #3) @2024-05-02T15:25:32-04:00@ Check permissions Allows No email address match for current mailbox, checking current user specific allows Email address: Mailbox and current user do not have any allowed email address Do not use template as there is no allow or at least one deny Process replacementvariable specific templates @2024-05-02T15:25:32-04:00@ Set up environment for connection to Outlook Web @2024-05-02T15:25:32-04:00@ **Connect to Outlook Web** ... Using the following options when starting the script (I have replaced actual fileserver name and share) & '\\fileserver\share\OutlookSignatureTemplate\set-outlooksignatures.ps1' ` -SignatureTemplatePath "\\fileserver\share\OutlookSignatureTemplate\DOCX" ` -SignatureIniPath '\\fileserver\share\OutlookSignatureTemplate\Config\_Signatures.ini' ` -OOFTemplatePath "\\fileserver\share\OutlookSignatureTemplate\OOF" ` -OOFIniPath '\\fileserver\share\OutlookSignatureTemplate\Config\_OOF.ini' ` -GraphConfigFile '\\fileserver\share\OutlookSignatureTemplate\Config\GraphConfig.ps1' ` -GraphOnly $false ` -ReplacementVariableConfigFile '\\fileserver\share\OutlookSignatureTemplate\Config\ReplacementVars.ps1'

kerem

2026-02-27 20:30:59 +03:00

closed this issue
added the
wontfix

invalid
labels

kerem commented

2026-02-27 20:30:59 +03:00

Author

Owner

@GruberMarkus commented on GitHub (May 2, 2024):

Please provide the full text output when run with the -verbose parameter.

@GruberMarkus commented on GitHub (May 2, 2024): Please provide the full text output when run with the -verbose parameter.

kerem commented

2026-02-27 20:30:59 +03:00

Author

Owner

@stipman commented on GitHub (May 2, 2024):

Script seems to hang for 5 minutes before completing
I have included the verbose log
VerboseOutput.txt

@stipman commented on GitHub (May 2, 2024): Script seems to hang for 5 minutes before completing I have included the verbose log [VerboseOutput.txt](https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/files/15194011/VerboseOutput.txt)

kerem commented

2026-02-27 20:30:59 +03:00

Author

Owner

@GruberMarkus commented on GitHub (May 3, 2024):

The issue happens in the following part of the verbose output:

  Set up environment for connection to Outlook Web @2024-05-02T16:31:02-04:00@
VERBOSE: Loading module from path 'C:\Users\MyUser\AppData\Local\Temp\f8974761-7afe-4f4f-bb38-0115c67d8844.dll'.
  Connect to Outlook Web
VERBOSE:     Try Integrated Windows Authentication
VERBOSE:       EXO access token available, skip Integrated Windows Authentication
VERBOSE:     Try OAuth with Autodiscover
VERBOSE: Exception calling "AutodiscoverUrl" with "2" argument(s): "The Autodiscover service couldn't be located."
VERBOSE:     Try OAuth with fixed URL
  Set classic Outlook Web signature @2024-05-02T16:34:23-04:00@

Set-OutlookSignatures tries to connect to Outlook Web up to three times:

Using Integrated Windows Authentication with Autodiscover. This is skipped when a Graph token with Exchange Online rights is available.
OAuth with Autodiscover, using the logged-in users mail address configured in Outlook ('MyUser@MyCompany.com' in your log). This means that the Autodiscover URL is defined dynamically (which is what should work anyway).
OAuth with Autodiscover, but using a fixed URL for the different M365 clouds (public, China, US Government, US Government DoD)

In your case, step 1 is skipped because an OAuth access token is already available, so things are faster when directly using this token for authentication.

Step 2 runs into a non-interruptable timeout because autodiscover for 'MyUser@MyCompany.com' does not work. The configuration issue is very like in your on-prem enviroment or in a part of the public infrastructure you control:

Internal DNS domain 'MyCompany.com' and its parent domains
Internal Exchange servers (if you still have some)
Load balancers, firewalls, ...
External DNS domain 'MyCompany.com' and its parent domains

Why am I sure that the problem is not within Set-OutlookSignatures? Because step 3 works fine and does not throw an error. Step 3 is exactly the same as step 2, but does not use Autodiscover to find the endpoint for authentication, but uses a fixed one.

Why is step 2 used anyhow, when step 3 always works? Autodiscover is an essential service for Exchange, so it should be configured correctly. Using a fixed URL is not guaranteed to work and should only be the last resort.

The next release of Set-OutlookSignatures, which is already in the final stages of testing, will contain a hint in standard output.

When you begin analyzing the problem, you will very like use Outlook's Test Email AutoConfiguration internally and Microsoft's Remote Connectitivy Analyzer externally, and at least one of these tools will show you the same error.

You probably see the problem in Outlook only when running it for the first time, because Outlook not only uses a fallback like Set-OutlookSignatures, but also a Last Known Good cache for Autodiscover.

Should you seek external help for solving this topic, ExplicIT Consulting, which I am associated with, might be an option for you.

As this is not a problem within Set-OutlookSignatures or it's components, I would like to close this issue.
Please let me know if your questions have been answered and if you agree to close this issue.

@GruberMarkus commented on GitHub (May 3, 2024): The issue happens in the following part of the verbose output: ``` Set up environment for connection to Outlook Web @2024-05-02T16:31:02-04:00@ VERBOSE: Loading module from path 'C:\Users\MyUser\AppData\Local\Temp\f8974761-7afe-4f4f-bb38-0115c67d8844.dll'. Connect to Outlook Web VERBOSE: Try Integrated Windows Authentication VERBOSE: EXO access token available, skip Integrated Windows Authentication VERBOSE: Try OAuth with Autodiscover VERBOSE: Exception calling "AutodiscoverUrl" with "2" argument(s): "The Autodiscover service couldn't be located." VERBOSE: Try OAuth with fixed URL Set classic Outlook Web signature @2024-05-02T16:34:23-04:00@ ``` Set-OutlookSignatures tries to connect to Outlook Web up to three times: 1. Using Integrated Windows Authentication with Autodiscover. This is skipped when a Graph token with Exchange Online rights is available. 2. OAuth with Autodiscover, using the logged-in users mail address configured in Outlook ('MyUser@MyCompany.com' in your log). This means that the Autodiscover URL is defined dynamically (which is what should work anyway). 3. OAuth with Autodiscover, but using a fixed URL for the different M365 clouds (public, China, US Government, US Government DoD) In your case, step 1 is skipped because an OAuth access token is already available, so things are faster when directly using this token for authentication. Step 2 runs into a non-interruptable timeout because autodiscover for 'MyUser@MyCompany.com' does not work. The configuration issue is very like in your on-prem enviroment or in a part of the public infrastructure you control: - Internal DNS domain 'MyCompany.com' and its parent domains - Internal Exchange servers (if you still have some) - Load balancers, firewalls, ... - External DNS domain 'MyCompany.com' and its parent domains Why am I sure that the problem is not within Set-OutlookSignatures? Because step 3 works fine and does not throw an error. Step 3 is exactly the same as step 2, but does not use Autodiscover to find the endpoint for authentication, but uses a fixed one. Why is step 2 used anyhow, when step 3 always works? Autodiscover is an essential service for Exchange, so it should be configured correctly. Using a fixed URL is not guaranteed to work and should only be the last resort. The next release of Set-OutlookSignatures, which is already in the final stages of testing, will contain a hint in standard output. When you begin analyzing the problem, you will very like use Outlook's Test Email AutoConfiguration internally and Microsoft's Remote Connectitivy Analyzer externally, and at least one of these tools will show you the same error. You probably see the problem in Outlook only when running it for the first time, because Outlook not only uses a fallback like Set-OutlookSignatures, but also a Last Known Good cache for Autodiscover. Should you seek external help for solving this topic, [ExplicIT Consulting](https://explicitconsulting.at/), which I am associated with, might be an option for you. As this is not a problem within Set-OutlookSignatures or it's components, I would like to close this issue. Please let me know if your questions have been answered and if you agree to close this issue.

kerem commented

2026-02-27 20:30:59 +03:00

Author

Owner

@GruberMarkus commented on GitHub (May 7, 2024):

Closing issue due to inactivity. @stipman: Should you see something regarding this issue that I did answer, you can re-open this issue.

@GruberMarkus commented on GitHub (May 7, 2024): Closing issue due to inactivity. @stipman: Should you see something regarding this issue that I did answer, you can re-open this issue.