Data Application Lifecycle Management
We moeten vaak een productiedatabase terugzetten in een sandboxomgeving. Bijvoorbeeld om de training van nieuwe medewerkers te ondersteunen, een productieprobleem te debuggen en vast te stellen, destructieve tests uit te voeren, of configuratiewijzigingen te evalueren zonder de live-omgeving te veranderen. In het verleden moest je een ondersteuningsverzoek openen om dit door het Microsoft Service Engineering-team te laten behandelen. Dit betekende urenlang wachten, waarbij veel (soms kostbare) tijd verloren ging, zoals in het geval van een urgent probleem dat een grote impact had op de business van de klant.
Nog niet zo lang geleden introduceerde Microsoft echter LCS “Self-Service Database Refresh”. Wat een geweldige functie is dat! Het maakt ons leven zo veel gemakkelijker, tenminste in het licht van Data Application Lifecycle Management (DataALM). In deze tweedelige blogserie vertel ik er meer over.
Point-In-Time Restore
Tegenwoordig kunnen we gewoon inloggen op LCS, naar de Environment Details pagina gaan van de omgeving waarin we de database willen verversen en “Verplaats database” selecteren in het menu Maintain. Vervolgens kiezen we:
Daarna specificeren we het herstelpunt in de tijd, dat is de gewenste exacte datum en tijd van een eerder gemaakte automatische back-up, druk op Submit…
… en daar gaan we. Ongeveer een uur later hebben we de productiegegevens beschikbaar in onze sandbox!
Voorbereidingen
Voordat u de refresh uitvoert, wilt u misschien een back-up maken van uw nieuw aangemaakte financiële rapporten, beveiligingsconfiguraties, gegevensbeheersjablonen en/of specifieke instellingsgegevens die nog niet beschikbaar zijn in productie en moeten worden opgeslagen.
Daarna dient u de gebruikers van de doelomgeving te informeren dat de omgeving gedurende enige tijd offline zal zijn en dat zij zich daarvoor moeten afmelden, om te voorkomen dat er boze gebruikers zijn die automatisch uit de omgeving zijn gezet.
Voorzorgsmaatregelen van Microsoft
De productiedatabase bevat natuurlijk veel omgeving-specifieke data die je niet in je sandbox wilt hebben en die zijn eigen specifieke instellingen nodig heeft. Wanneer de productiedatabase gekopieerd zou zijn zoals ze is, zou dit kunnen resulteren in ongewenst gedrag zoals het versturen van dubbele emails omdat SMTP nog steeds ingeschakeld is in de doelomgeving, het versturen van ongeldige integratie berichten omdat batch jobs nog steeds ingeschakeld zijn, enzovoort. Om dit soort problemen in de doelomgeving te voorkomen, heeft Microsoft enkele noodzakelijke voorzorgsmaatregelen genomen door bepaalde elementen van de database niet naar de doelomgeving te kopiëren, bijvoorbeeld:
- Emailadres informatie
- SMTP Relay server in de e-mail parameters
- Afdrukbeheerinstellingen van Crediteuren en Debiteuren
- Serverconfiguraties, batch-servergroepen, netwerkprintergegevens, client- en serverinstellingen
- Dual-write instellingen
- Alle gebruikers zijn uitgeschakeld, behalve de Admin-gebruiker die als enige nog beschikbaar is
- Alle batchtaken zijn ingesteld op Withhold
- Alle wijzigings-tracking op gegevensentiteiten is uitgeschakeld
- Alle velden met Microsoft-encryptie worden gewist (omdat ze niet op een andere databaseserver kunnen worden gedecodeerd)
Post-refresh cleanup activiteiten
Zoals reeds vermeld, heeft na de database refresh alleen de Admin gebruiker toegang tot de sandbox omgeving. Dit stelt de Admin gebruiker in staat om enkele extra opruim- en herconfiguratie-activiteiten uit te voeren alvorens de andere gebruikers weer toe te laten tot het systeem. Dit zijn activiteiten zoals:
- Het herstellen van financiële rapporten, beveiligingsconfiguraties, gegevensbeheersjablonen en/of specifieke instellingsgegevens vanuit de back-ups die in de voorbereidingsfase zijn gemaakt
- Integratie-eindpunten opnieuw verbinden met specifieke niet-productieservices of -URL’s
- De BYOD Entity store-verbindingsreeks opnieuw invoeren (een gecodeerd veld dat werd gewist)
- Wisselkoersproviders opnieuw configureren (die ook gewiste versleutelde velden bevatten)
- De instellingen voor afdrukbeheer voor crediteuren en debiteuren opnieuw configureren
- Specificeren van omgeving-specifieke Gebruikersopties Kleurenthema’s en de juridische entiteit Dashboard bedrijfsafbeeldingstypes om de sandbox omgeving duidelijker van productie te onderscheiden
- Toevoegen van de verschillende AOS instances aan de door u gewenste batch server groepen
- Vernieuwen van de gegevensentiteiten die nodig zijn voor Microsoft Power BI-rapportage
- De omgeving opnieuw verbinden met de LCS Help-configuratie voor taakgidsen
- De SMTP-instellingen invoeren als u e-mail in uw sandboxomgeving wilt gebruiken
- De batch-taken die u in uw sandbox-omgeving wilt uitvoeren, opnieuw activeren
- Aanvullende herconfiguratie gebaseerd op uw setup en de geïnstalleerde ISV-oplossingen
Laatste stap
Tenslotte, wanneer alle activiteiten zijn voltooid en het systeem is geconfigureerd zoals u wenst, kunt u de geselecteerde gebruikers inschakelen en laten weten dat ze weer toegang hebben tot de omgeving. Indien veel gebruikers moeten worden geactiveerd, kunt u deze taak sneller uitvoeren door gebruik te maken van de Microsoft Excel Add-In.
Conclusie
Dat was het voor nu. In het eerste deel van deze blogserie hebben we een voorbeeld gezien van DataALM, hoe je een geautomatiseerde database restore uitvoert, welke voorbereidingen gedaan kunnen worden, en welke post-refresh opruimactiviteiten nodig zijn. In het tweede (en laatste) deel zal ik enkele opties bespreken om de vereiste herconfiguraties efficiënter af te handelen. Tot de volgende blog!
