starred/Set-OutlookSignatures-Set-OutlookSignatures

Fork 0

mirror of https://github.com/Set-OutlookSignatures/Set-OutlookSignatures.git synced 2026-04-26 18:55:53 +03:00

[GH-ISSUE #83] Can't access local AD #30

New issue

Closed

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

kerem commented

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

Owner

Originally created by @panki27 on GitHub (Aug 16, 2023).
Original GitHub issue: https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/issues/83

Originally assigned to: @panki27 on GitHub.

Hi, I've tried running Set-OutlookSignatures for the first time.
The script throws an error while trying to access the on-prem AD. I believe this is happening because the forest name is identical to the domain name.

Output (sorry for the German verbose message - I don't think there's a way to easily change this, other than changing entire OS language...):

Enumerate domains @2023-08-16T10:53:15+02:00@
  User forest: contoso.com
    Child domain: a.contoso.com
    Child domain: b.contoso.com
    Child domain: c.contoso.com
    Child domain: d.contoso.com
    Child domain: e.contoso.com
    Child domain: f.contoso.com
    Child domain: g.contoso.com
    Child domain: h.contoso.com
    Child domain: i.contoso.com
    Child domain: j.contoso.com
    Child domain: k.contoso.com
    Child domain: l.contoso.com
  Trusted domain: contoso.com
AUSFÜHRLICH: Ausnahme beim Aufrufen von "Add" mit 2 Argument(en):  "Das Element wurde bereits hinzugefügt. Schlüssel im Wörterbuch: "contoso.com". Hinzuzufügender Schlüssel: "contoso.com"."
  Problem connecting to logged-in user's Active Directory (see verbose stream for error message).
  Assuming Graph/Entra ID/Azure AD from now on.

The issue is here: github.com/GruberMarkus/Set-utlookSignatures@dfae4b37a8/src_Set-OutlookSignatures/Set-OutlookSignatures.ps1 (L1170)

Debugging the $LookupDomainsToTrusts variable shows that it already contains contoso.com, which is then being added a second time, which leads to the above exception.

I was able to work around it like this:

if ( -not $LookupDomainsToTrusts[$TrustedDomain.properties.name]) {
    $LookupDomainsToTrusts.add($TrustedDomain.properties.name.tolower(), $TrustedDomain.properties.name.tolower())
}

But I'm not sure if this is the best approach. If you think it is, let me know and I'll create a PR.

Originally created by @panki27 on GitHub (Aug 16, 2023). Original GitHub issue: https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/issues/83 Originally assigned to: @panki27 on GitHub. Hi, I've tried running Set-OutlookSignatures for the first time. The script throws an error while trying to access the on-prem AD. I believe this is happening because the forest name is identical to the domain name. Output (sorry for the German verbose message - I don't think there's a way to easily change this, other than changing entire OS language...): ``` Enumerate domains @2023-08-16T10:53:15+02:00@ User forest: contoso.com Child domain: a.contoso.com Child domain: b.contoso.com Child domain: c.contoso.com Child domain: d.contoso.com Child domain: e.contoso.com Child domain: f.contoso.com Child domain: g.contoso.com Child domain: h.contoso.com Child domain: i.contoso.com Child domain: j.contoso.com Child domain: k.contoso.com Child domain: l.contoso.com Trusted domain: contoso.com AUSFÜHRLICH: Ausnahme beim Aufrufen von "Add" mit 2 Argument(en): "Das Element wurde bereits hinzugefügt. Schlüssel im Wörterbuch: "contoso.com". Hinzuzufügender Schlüssel: "contoso.com"." Problem connecting to logged-in user's Active Directory (see verbose stream for error message). Assuming Graph/Entra ID/Azure AD from now on. ``` The issue is here: https://github.com/GruberMarkus/Set-utlookSignatures/blob/dfae4b37a84987ed76dc962b0fe52e29260019de/src_Set-OutlookSignatures/Set-OutlookSignatures.ps1#L1170 Debugging the `$LookupDomainsToTrusts` variable shows that it already contains `contoso.com`, which is then being added a second time, which leads to the above exception. I was able to work around it like this: ``` if ( -not $LookupDomainsToTrusts[$TrustedDomain.properties.name]) { $LookupDomainsToTrusts.add($TrustedDomain.properties.name.tolower(), $TrustedDomain.properties.name.tolower()) } ``` But I'm not sure if this is the best approach. If you think it is, let me know and I'll create a PR.

kerem closed this issue

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

kerem commented

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

Author

Owner

@GruberMarkus commented on GitHub (Aug 16, 2023):

Deutsch ist überhaupt kein Problem. But let's stick to English, to make it easier for other users to follow this issue.

You are right with your assumption and your sample code would work. I will consider integrating the code in the next hotfix release - but we must find the root cause first: Why does Set-OutlookSignature detect this specific trust anyhow?

Please open the Active Directory Domains and Trusts MMC snap-in and check, if the root domain contoso.com has configured a trust to itself. If yes, than this is something you should investigate (I have never seen such a configuration, and ad-hoc can't imagine why this would be neccessary).

@GruberMarkus commented on GitHub (Aug 16, 2023): Deutsch ist überhaupt kein Problem. But let's stick to English, to make it easier for other users to follow this issue. You are right with your assumption and your sample code would work. I will consider integrating the code in the next hotfix release - but we must find the root cause first: Why does Set-OutlookSignature detect this specific trust anyhow? Please open the Active Directory Domains and Trusts MMC snap-in and check, if the root domain contoso.com has configured a trust to itself. If yes, than this is something you should investigate (I have never seen such a configuration, and ad-hoc can't imagine why this would be neccessary).

kerem commented

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

Author

Owner

@panki27 commented on GitHub (Aug 16, 2023):

Hi Markus,
I've checked this by opening the properties of the root domain contoso.com and checking the list of outgoing and incoming trusts.

There is no reference to contoso.com, only to the child domains a.contoso.com, b.contoso.com and so on.
But thank you for this hint, I'll keep investigating.

@panki27 commented on GitHub (Aug 16, 2023): Hi Markus, I've checked this by opening the properties of the root domain `contoso.com` and checking the list of outgoing and incoming trusts. There is no reference to `contoso.com`, only to the child domains `a.contoso.com`, `b.contoso.com` and so on. But thank you for this hint, I'll keep investigating.

kerem commented

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

Author

Owner

@panki27 commented on GitHub (Aug 16, 2023):

After using several Powershell cmdlets, I can confidently say there is no "special" trust relation from the parent domain to itself (which would be really weird, indeed).

My guess is that this happens because forest name == domain name, which is against M$ best practice. So I really can't fault your script here!

@panki27 commented on GitHub (Aug 16, 2023): After using several Powershell cmdlets, I can confidently say there is no "special" trust relation from the parent domain to itself (which would be really weird, indeed). My guess is that this happens because forest name == domain name, which is against M$ best practice. So I really can't fault your script here!

kerem commented

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

Author

Owner

@GruberMarkus commented on GitHub (Aug 16, 2023):

Nonetheless, the code change you proposed makes sense and I will integrate it in the next hotfix release (which will very likely be released until the end of this week).

@GruberMarkus commented on GitHub (Aug 16, 2023): Nonetheless, the code change you proposed makes sense and I will integrate it in the next hotfix release (which will very likely be released until the end of this week).

kerem referenced this issue

2026-02-27 20:31:12 +03:00

[PR #30] [MERGED] v2.5.1 #88