Feilsøking i AD-synkroniseringa

1.1   Er powershell installert og kva versjon

Det kan av og til vere problem med at powershell ikkje finnast, eller at det er installert ein versjon vi ikkje har testa før, som skaper ukjende problem.

Du kan sjå om powershell er installert og kva versjon ved å sjekke registry

Dersom du får starta powershell, kan du hente ut powershell-versjonen med:

$ powershell.py --type SPREAD_OR_TYPE \$PSVersionTable.psversion

Du kan også sjekke om vi bruker riktig fil-lokasjon for powershell, med:

$ cmd.py --type SPREAD_OR_TYPE where powershell.exe

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe

2.1   The name reference is invalid

Om du får feil av typen:

New-ADUser : The name reference is invalid

kan det dessverre bety mange forskjellige ting.

Dette kan til dømes bety at eit attributt som skal settast eller endrast enten ved oppretting eller oppdatering av eit objekt ikkje følger namnekrav. Eit døme kan vere at attributtet homeMDB ikkje peiker på ein eksisterande OU, eller at vi prøver å legge til Exchange-attributtar utan at Exchange er installert - typisk attributtet AltRecipient.

2.2   The server is unwilling to process the request

Feil av typen:

New-ADUser : The server is unwilling to process the request

er generelle, og kan bety at data du sender med er ugyldig. Feilmeldinga kan til dømes komme av at eit array ikkje er formatert korrekt.

2.3   The specified value already exists

Feil av typen:

New-ADUser : The specified value already exists

betyr som oftast at eit attributt er ugyldig. Til dømes krever attributtet SAMAccountName at det skal vere unikt i heile AD-domenet, men det er ikkje alltid du får ei forklarande feilmelding på slikt. Det vil dessverre av og til kreve litt feilsøking, til dømes ved å kommentere ut enkeltattributtar.

2.4   Get-ADDomainController: A local error has occurred

Feil av typen:

Get-ADDomainController : A local error has occurred

kjem av AD-interne feil. Til dømes kan DC-en ha gått ned, eller så kan maskina vi kobler oss til ha mista tilgangen sin til domenet. Det kan vere mange feil, men AD skal kunne fikse opp i dette på eigenhand.

Dersom denne feilen gjentek seg fleire ganger må AD-administratorane bli kontakta. Vi kan vanlegvis ikkje fikse denne feilen.

2.5   A global group cannot have a universal group as a member (og liknande)

Feil av typen:

Set-ADObject : A global group cannot have a universal group as a member

betyr at vi prøver å legge til ei gruppe i ei anna gruppe, der gruppene har ulikt scope (td. synlighet lokalt i domenet eller i ein heil forest). Grupper med ulikt scope passer ikkje alltid saman.

For å løyse dette problemet må ein av gruppene bli konverterte. Dette kan gjerast med:

Set-ADGroup -Credential $cred -Identity TARGETGROUP -GroupScope [universal|global]

Ideelt sett bør alle grupper ha samme scope. Dette må avtalast med instansen, men det kan utførast med:

Get-ADGroup -Credential $cred -Filter { GroupScope -eq "[global|universal]" }  -SearchBase OU=Groups,OU=Cerebrum,DC=... | Set-ADGroup -Credential \$cred -GroupScope [universal|global]

Obs: Bytt ut [global|unversial] med enten global eller universal.

Denne kommandoen vil kunne bruke litt tid.

2.6   Feila flyttingar

Dersom eit objekt ikkje vil bli flytta til riktig OU, kan dette komme av ein feil i synken. Du kan tvinge flyttinga med kommandoen:

Move-ADObject -Credential $cred -Identity USERNAME -TargetPath 'TARGETPATH'

til dømes:

Move-ADObject -Credential $cred -Identity mrbob -TargetPath 'OU=Users,OU=Cerebrum,DC=uio,DC=no'

Du kan då få ei feilmelding om at vi ikkje har rettigheter til å flytte brukaren. Instansen må då bli informert, og har i hovudsak alternativa:

1. Flytte AD-objektet til riktig OU, sidan det ser ut til at vi ikkje har rettigheter til OU-et objektet ligg i.
2. Fjerne entiteten frå Cerebrum dersom det er meininga at vi ikkje skal oppdatere dette objektet. Dette er då ein namnekollisjon.

2.7   System.OutOfMemoryException

Denne feilmeldingen er egentlig ganske selvforklarende. Om AD-tjeneren tilsynelatende har en del minne til overs, bør man ta en titt på hva MaxMemoryPerShellMB er satt til. Dette kan gjøres slik:

PS> Get-Item wsman:localhost\Shell\MaxMemoryPerShellMB
eller
cmd> winrm get winrm/config

Denne bør være satt til 1024-2048 MB.

3.1   Konfigureringa av WinRM

Hent ut konfigurasjonen til WinRM på maskina vi snakker med med:

$ cmd.py --type SPREAD_OR_TYPE winrm get winrm/config

alternativt:

$ powershell.py --type SPREAD_OR_TYPE winrm get winrm/config

Samanlikn oppsettet med det som er beskreve i dokumentet Oppsett av AD-synken for Windows-sida.

Du kan også sjekke om det er satt opp riktige listeners:

$ powershell.py --type SPREAD_OR_TYPE winrm enumerate winrm/config/listener

og samanlikne med det som er dokumentert i oppsettsdokumentet referert til over. Dette er uansett vanskeleg å feilsøke frå Cerebrum si side, då ein som oftast treng dette når ein ikkje får kobla til maskina.

3.2   Lokal administrator-tilgang

For å sjå kven som er lokal administrator på windows-maskina vi logger på:

powershell.py --type SPREAD_OR_TYPE 'Get-WmiObject win32_groupuser | Where-Object { $_.GroupComponent -match ' "'administrators'" ' } | ForEach-Object {[wmi]$_.PartComponent }'

5.1   Køyre events på nytt

I visse situasjonar kan det hende at du treng å få køyrd ein event på nytt. Til dømes kanskje ei passordoppdatering feila på Windows-sida, sjølv om Cerebrum fekk ein ack tilbake.

Dette kan du gjere med:

python sync.py --type SYNCTYPE --change-id CHANGELOGID

Det CHANGELOGID er nummeret på eventen du vil køyre på nytt. Synken køyrer då denne på nytt og avslutter.