TL;DR: een mislukte persoonsimport maakt meer kapot dan je lief is. Dit overkwam een organisatie, die met de gebakken peren (en 435 dubbele entries) zat. In drie posts laat ik zien wat er is gebeurd, en wat ik heb gedaan om het te repareren.
Wat doe je als je 435 dubbele records hebt in je database? En wat doe je wanneer die dubbele records ook nog gekoppeld zijn aan andere records in tabellen? En wat als je database dan ook nog in de cloud staat, omdat je TOPdesk SAAS hebt? Dan heb je een hoofdpijndossier.
Onlangs was ik bij een organisatie met dit probleem. Door een mislukte persoonsimport uit Active Directory waren er 435 persoonskaarten dubbel aangemaakt als personen in TOPdesk. Er was zowel een actieve als een gearchiveerde persoonskaart aanwezig. Allerlei functionaliteit in TOPdesk ging vervolgens kapot. In deze post laat ik zien hoe dit had kunnen gebeuren.
Wat was er gebeurd?
In een eerdere post heb ik wat achtergrond gegeven over aangepaste imports. Voor deze organisatie had TOPdesk een aangepaste import gemaakt, een persoonsimport uit het AD. Deze draaide maanden goed. De import maakte persoonskaarten aan wanneer iemand in dienst kwam, en archiveerde persoonskaarten wanneer ze niet meer in het AD actief waren. Tenslotte was de import zo ingesteld dat mensen die ooit in dienst waren geweest, geen nieuwe persoonskaart kregen wanneer ze opnieuw in dienst kwamen. Met andere woorden, de import “hergebruikte” dus niet de oude persoonskaart.
Dit is de import-optie “Gearchiveerde kaarten automatisch dearchiveren”, en deze optie stond op Nee. Dit kun je opzoeken in het documentatiebestand van de aangepaste import.
Door nog onbekende oorzaak was er een incompleet bronbestand gegenereerd uit het AD: in het bronbestand stonden maar 897 personen, in plaats van 1332 personen. TOPdesk interpreteerde deze situatie alsof 435 personen uit dienst waren, en archiveerde deze 435 persoonskaarten. Al die mensen konden toen niet inloggen op de SelfServicePortal. Een dag later draaide de import opnieuw, en ditmaal stonden wel alle 1332 personen in het bronbestand. Maar, zoals gezegd, TOPdesk keek niet naar oude persoonskaarten, en dus maakte TOPdesk gewoon 435 nieuwe personen aan.
Deze 435 mensen konden vervolgens wel weer inloggen op de SelfServicePortal, maar allerlei functionaliteit was toen stuk gegaan. Het grootste probleem was dat alle tickethistorie weg was, want die tickets waren gekoppeld aan de gearchiveerde persoonskaart. Verder verloren mensen hun rechten op de SelfServicePortal, zodat werkprocessen niet meer op de juiste manier konden starten. Ook werden ingeplande rapporten niet meer verstuurd, en waren CMDB-items niet meer gekoppeld. Allemaal schraal, en dat kon dus gebeuren omdat 1 specifiek import-optie op Nee stond.
Analyse
Vanwege de complexiteit van deze verstoring, en vanwege het feit dat Aangepaste imports niet gedocumenteerd zijn, kon dit niet zomaar opgelost worden. In de tussentijd werd een nieuwe tickethistorie opgebouwd: alle meldingen en wijzigingen die na de verstoring werden aangemaakt, werden gekoppeld aan de 435 nieuwe persoonskaarten.
Het was een maand na deze verstoring dat ik bij deze organisatie over de vloer kwam, en dit was het grootste openstaande probleem. Al snel bleek wat de oorzaak van het probleem was, en het was duidelijk dat er een soort databaseconversie zou moeten plaatsvinden. TOPdesk draaide echter op SAAS, dus dat was niet zomaar gedaan. Verder was er ook nog geen uitgewerkte oplossingsrichting voor handen. De grootste drie problemen waren als volgt:
Ten eerste, als je de 435 oude personen dearchiveert en de verkeerd aangemaakte personen archiveert dan verliezen deze 435 mensen opnieuw de opgebouwde tickethistorie van de afgelopen maand. Dat aantal was al opgelopen tot een paar honderd, dus dat was niet de bedoeling. Dat betekent dus dat sowieso al deze tickets moesten worden herkoppeld.
Ten tweede, als je tickets gaat herkoppelen van de verkeerd aangemaakte persoonskaart naar de oude persoonskaart, dan heb je een mapping nodig: oude waarde aanmelder -> nieuwe waarde aanmelder. Probleem is dat de verkeerd aangemaakte nieuwe persoonskaart en de oude persoonskaart nagenoeg identiek zijn. Voornaam, achternaam, emailadres, loginnaam, etc, alles heeft TOPdesk overgenomen uit het AD. Dat zijn dus geen velden waar je wat aan hebt in de mapping. Je hebt dus een veld nodig dat echt uniek is. Dat is het veld unid, de unieke identifier die TOPdesk onder water gebruikt.
Ten derde, werken met persoonskaarten vereist extra aandacht. Doe je het verkeerd, dan zet je de deur open voor datalekken. Voorbeeldje: koppel je tickets aan de verkeerde personen, dan hebben zij inzage in tickets en informatie die niet voor hen bestemd is. Het is niet ondenkbaar dat er dan plain text wachtwoorden te zien zijn, bijvoorbeeld in het geval van een password-reset-verzoek. De mapping oude waarde aanmelder -> nieuwe waarde aanmelder moet dus absoluut goed zijn.
Oplossingsrichting
Nadat we alles op een rijtje hebben gezet, was mijn inschatting dat het wel degelijk haalbaar was om de situatie weer te herstellen. TOPdesk heeft namelijk een tooltje, de CSV-wizard waarmee je exportjes uit de database kunt maken. TOPdesk installeert deze add-on op SAAS op verzoek. Met de exports van de CSV-wizard kun je dan met Excel weer mappings op unid maken. In twee hoofdstappen kun je dan de mislukte persoonsimport weer terugdraaien.
Stap 1: het herkoppelen van een paar honderd tickets. Dat gaat om de tickets die waren geregistreerd na de verstoring, en die dus aan de verkeerd aangemaakte persoonskaart hingen.
Stap 2: de verkeerd aangemaakte persoonskaarten archiveren en ontdubbelen, en de persoonsimport zo aanpassen dat dit niet nogmaals kan voorkomen.
* Volgende keer deel twee over het repareren van een mislukte persoonsimport: het herkoppelen van een paar honderd tickets. In de derde post zoom ik in op het ontdubbelen van de persoonskaarten.
