AD Migration - Änderungen an Postentabellen?

18. Oktober 2018 22:29

Im Rahmen einer AD-Migration ändern sich die Benutzernamen und die SID. In zahlreichen Tabellen sind Verweise auf den User bzw. die USer-ID aus der Tabelle User Setup. Das Ersetzen der bisherigen durch die neue UserID in normalen Tabellen ist nicht das Thema, dauert ggf.lange aber ist technisch überschaubar. Bei den Postentabellen kann man durchaus diskutieren, ob bspw. in den Sachposten das Feld "Erstellt von" geändert wird oder nicht. Auch bei den gebuchten Genehmigungsposten kann man überlegen, ob man die UserID auf den aktuellen Wert ändert, da der alte Domänencontroller ab einem bestimmten Zeitpunkt abgeschaltet wird und damit auch keine historischen Daten mehr verfügbar sind. Daher existiert auf Kundenseite der starke Wunsch, in einigen wenigen Postentabellen die UserID zu aktualisieren, um schnell eine Aussage zur Identität der Nutzer treffen zu können. Nun kommt die eigentliche Frage: Gibt es eine harte Regel seitens MS, daß solche Änderungen nicht legitim sind und ggf. negative Auswirkungen auf die Produkthaftung haben können? Der MS Partner weigert sich quasi, Postentabellen zu ändern und der Kunde kann es mit der eigenen Lizenz nicht selbst umsetzen. Weiterhin interessiert es mich, ob es zu dieser Thematik bereits praktische Erfahrungen im Hinblick auf dem Umfang des Ersetzens von alter mit neuer UserID gibt?

Danke und Gruß,
clew

Re: AD Migration - Änderungen an Postentabellen?

18. Oktober 2018 23:22

Das ist eine Philosophie-Frage. Ich würde die Benutzer ID Felder in den Posten-Tabellen nicht ändern.

Sofern die Windows User SID gleich bleibt muss am Benutzer in NAV ja nix geändert werden da User Security ID der Primärschlüssel ist. Man kann dann programmiert User Name ändern. Bei dir gibt's aber neue SIDs. Daher muss man die Benutzer ja neu in NAV anlegen. Das würde ich ja auch programmiert machen, und da du dann ohnehin eine Zuordnung alt->neu haben müsstest könntest du auch die User ID Felder in den Posten gleich mit ändern. Dafür brauchst du natürlich die entsprechenden Rechte bzw. Lizenz.

Warum der Partner sich weigern sollte weiß ich nicht. Der Kunde ist verantwortlich für den Umgang mit NAV. Man kann sich ja absichern und sich diese Änderung explizit unterschreiben lassen. Ansonsten ist das programmtechnisch keine große Kunst. Man muss sich nur überlegen wo man's überall macht (gebuchte Posten, gebuchte Belege, die angelegt/korrigiert von Felder in Stammdatentabellen, Genehmigungsposten, Notifications, Bemerkungstabellen, ...).

Re: AD Migration - Änderungen an Postentabellen?

19. Oktober 2018 06:07

Hallo,

solltet ihr mit soetwas wie "Zugeordneter Benutzer" oder Filterungen nach der USERID arbeiten, damit jeder nur seins sieht, kommst du um die Umbenennung nicht herum. :-?

Man muss in NAV auch unterscheiden, ob man die USERID oder die USERSID meint. Letztere wird im Standard eher selten nur beim Zugriff auf systemnahe Funktionen verwendet. In den Tabellen steht meist die Textform.
in NAV gab es diese Umbenennung übrigens auch im Standard schon mal beim Umstieg von der native- Datenbank auf den SQL-Server, da auch dort aus den Native- Benutzern meist Windows Benutzer wurden. Evtl. kann euer Partner sich hier Anregungen holen.

Generell ist das größte Problem herauszufinden wo man überall ändern muss. Bei vielen ISV- Lösungen, auf die der Partner keinen Zugriff hat, kann das schwierig werden alle zu finden. Eine Hilfe kann hier die virtuelle Tabelle Field sein, in der alle Felder einer Datenbank sichtbar sind. Hier kann man auf Feldnamen filtern, die auf Benutzernamen hindeuten filtern, und hat hoffentlich alle gefunden.

Dann muss man nur noch ein Programm schreiben, das die Felder neu befüllt. Ob man das den SQL-Server per Skript machen lässt, oder in NAV mit einem Report oder dem Code aus dem Upgrade-Toolkit macht, hängt von eurer Datenbankgröße und der Zeit die euch für die Umbenennung zur Verfügung steht ab.

Gruß Fiddi

Re: AD Migration - Änderungen an Postentabellen?

2. November 2018 14:23

Hallo zusammen,

Danke für Eure Rückmeldungen und Anregungen. Schlußendlich wird es unser Partner innerhalb der DB umsetzen.
Danke auch für den Tipp mit dem SQL-Script, das wäre auch mein Vorschlag gewesen, aber auch da scheitert es an der Haltung des Partners zum generellen Einsatz von SQL-Scripten zur gezielten Änderung von Produktivdaten.

Wünsche ein schönes Wochenende!

Gruß
clew