Opsætning af postkasser i eADM

Denne artikel forklarer, hvordan eADM tildeler brugerens hovednavn (UPN), primær SMTP-adresse og e-mail-aliaser, samt hvordan oprettelsen af postkasser varierer mellem lokale Active Directory-modeller, hybridmodeller (fjerntliggende postkasser) og cloud-only .

Sådan tildeler eADM UPN og primær SMTP

eADM indstiller en brugers userPrincipalName (UPN) og den primære SMTP-adresse, når kontoen oprettes, baseret på de regler, der er konfigureret i synkroniseringsskabelonen. Disse regler anvender typisk organisatoriske data såsom navn, afdeling og stillingskode.

Normalt følger eADM princippet om én konto og én adgangskode. En medarbejder har én konto og én adgangskode på tværs af det lokale Active Directory, Entra ID og Google Workspace. UPN og primær SMTP kan indstilles i henhold til medarbejderens arbejdsplads. Hvis en medarbejder skifter stilling, for eksempel fra en sundhedsafdeling til en skole, kan e-mail-domænet opdateres automatisk, og den tidligere adresse bevares som et alias.

Brugere med flere arbejdsgivere og flere stillinger

I en eADM-tenant med flere organisationer importeres og sammenkædes stillingsoplysningerne for en medarbejder, der har stillinger i flere organisationer eller enheder, fra alle aktive ansættelsesforhold. Det nationale identifikationsnummer knytter posterne sammen på tværs af kildesystemerne. Adgangsrettighederne er kumulative: Brugeren får den samlede adgang fra alle aktive stillinger.

UPN og primær SMTP indstilles ud fra medarbejderens hovedstilling, f.eks. den stilling, der har den højeste procentdel eller den længste anciennitet. Dette kan konfigureres individuelt for hver kunde. Hvis et af ansættelsesforholdene ophører, inddrages kun den adgang, der er knyttet til netop den pågældende stilling. Der kan oprettes e-mail-aliaser for de øvrige ansættelsesforhold.

Lokale, eksterne og cloud-only

eADM understøtter flere integrationsniveauer med Microsofts katalogtjenester, lige fra en ren on-premises-opsætning til en cloud-only uden lokalt Active Directory:

Lokalt: Active Directory og Exchange på egne servere

eADM skriver ændringer direkte til det lokale Active Directory. Den eksisterende Microsoft Entra Connect Sync henter derefter ændringer vedrørende brugere, grupper og attributter og synkroniserer dem med Entra ID.

Fjernadgang: hybrid-Exchange med en fjernpostkasse

I et hybridmiljø administrerer eADM ikke Exchange direkte. I stedet skriver det de korrekte attributter til Active Directory-brugerobjektet og, hvor det er konfigureret, kører det et PowerShell-script på den lokale Exchange-server (typisk Enable-RemoteMailbox.ps1), eller via Exchange Management Tools, hvis der ikke længere findes en lokal Exchange-server. Dette opretter et fjernpostkasseobjekt, der knytter AD-brugeren til postkassen i Microsoft 365 og sikrer korrekt videresendelse af e-mails.

Cloud-only: Entra ID og Exchange Online

I en cloud-only administrerer eADM userPrincipalName og mailNickname direkte i Entra ID. UPN’en er altid den primære e-mailadresse, og Exchange Online tilføjer automatisk e-mail-kælenavnet på det primære domæne som et alias, så snart en licens er tildelt. Der kræves ingen lokal Active Directory- eller Exchange-server.

Primær SMTP-adresse og e-mail-aliaser

I Active Directory og Exchange gemmes en brugers e-mail-adresser i proxyAddresses attribut. Hovedadressen er markeret med et stort bogstav SMTP: præfiks; aliaser skal skrives med små bogstaver smtp: præfiks. Der kan kun være én primær adresse pr. konto ad gangen.

eADM understøtter to generelle metoder til at sikre, at denne attribut er korrekt:

• Minimal konfiguration. eADM indstiller kun mail attribut i Active Directory. Microsoft Entra Connect og Exchange Online udleder derefter proxyAddresses og hovedadressen automatisk ved hjælp af Microsofts standardadressepolitikker. Dette er nemt at konfigurere, men giver kun begrænset kontrol over navneændringer og yderligere aliaser.

• Scriptbaseret adressestyring. Et PowerShell-script, der udløses af eADM, beregner og angiver den primære adresse samt eventuelle aliaser eksplicit. Dette understøtter navneændringer med automatisk bevarelse af den gamle adresse som et alias, regler for flere domæner og andre kundespecifikke krav, dog på bekostning af yderligere scriptarbejde og vedligeholdelse.

Den rette fremgangsmåde afhænger af kompleksiteten i kundens navngivningsregler og domænestruktur. Identum kan rådgive om den mest passende model i forbindelse med onboarding.

Hvad ændrer sig, når man udskifter en Exchange-server?

Når en organisation udskifter eller opgraderer sin lokale Exchange-server, skal værtsnavnet eller FQDN’et for den nye server opdateres i det PowerShell-script, som eADM bruger. I de fleste standardkonfigurationer er dette $exchange variabel øverst i Enable-RemoteMailbox.ps1.

Afhængigt af, hvordan scriptet oprindeligt blev konfigureret, kan der være yderligere forbindelsesparametre, der skal gennemgås:

• $exchange, Exchange-serverens værtsnavn eller FQDN

• Loginoplysninger for servicekontoen, der bruges til at oprette forbindelse til Exchange, hvis den aktuelle Windows-session ikke anvendes

• Enhver eksplicit URI eller forbindelsesstreng i New-PSSession eller Connect-ExchangeServer

Advarsel: Du må ikke opdatere scriptet i produktionsmiljøet, uden først at have kontrolleret forbindelsen i testmiljøet. Et forkert konfigureret Exchange-endpoint medfører, at oprettelsen af postkasser for nye brugere mislykkes uden fejlmeddelelse, indtil problemet er løst.

Sådan opdateres henvisningen til Exchange-serveren

1. Find Enable-RemoteMailbox.ps1 script i eADM-synkroniseringskonfigurationen.

2. Opdater $exchange variabel til værtsnavnet eller FQDN for den nye Exchange-server.

3. Gennemgå eventuelle yderligere forbindelsesparametre (se listen ovenfor).

4. Test det opdaterede script manuelt på den nye server, inden du gemmer det i produktionskonfigurationen.

5. Udfør en testopsætning i eADM for at kontrollere, at den eksterne postkasse er oprettet korrekt.

6. Kontakt Identums support, hvis scriptet kræver ændringer, der går ud over $exchange variabel, eller hvis den aktuelle scriptkonfiguration er uklar.

Omfanget af Identum-supporten

Identum kan hjælpe med følgende, når en kundes Exchange-miljø ændres, eller når der skiftes mellem kontomodeller:

• Gennemgang og opdatering af $exchange variable og tilhørende parametre i eADM-opsætningsscriptet

• Rådgivning om den mest hensigtsmæssige fremgangsmåde i forbindelse med UPN, primær SMTP og administration af aliaser for kundens domænestruktur

• Test af opdateret konfiguration i et sandkasse-miljø

• Kontrol af, at nye brugerkonti er oprettet korrekt efter en ændring

Identum varetager ikke administration, konfiguration eller fejlfinding af selve Exchange-serveren eller Entra ID-tenantet. Ændringer af infrastrukturen, herunder installation, overgang til cloud-only certifikatadministration, er kundens IT-afdelings eller dennes Exchange- eller Entra ID-administrators ansvar.

Relaterede artikler

• Synkronisering — Active Directory og Azure AD

• Opdatering af brugerdata i eADM

• Kontakt Identums support

Denne artikel forklarer, hvordan eADM tildeler UPN, primær SMTP-adresse og e-mail-aliaser, samt hvordan oprettelsen af postkasser varierer mellem lokale Active Directory-modeller, hybridmodeller (fjernpostkasse) og cloud-only ID-kontomodeller, cloud-only . Den omhandler attributten proxyAddresses, scriptet Enable-RemoteMailbox.ps1 og variablen $exchange, der anvendes i hybridopsætninger, UPN-regler for flere arbejdsgivere samt omfanget af Identums support, når Exchange-servere skiftes ud, eller kunderne overgår til cloud-only. Artiklen henvender sig til IT- og Exchange-administratorer hos Identums kommunale kunder.

Senest opdateret: 20. juli 2026