Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Persönliche Anmeldeeinstellungen werden auf Ordner nicht „richtig“ migriert.
#1
Hallo,

wir testen gerade die neue 2015P8 Version. Die Migration der Daten aus der 2012 DB in die neue 2015 hat ohne Problem funktioniert.

Leider haben wir aber das Problem, dass die Anmeldeeinstellungen auf unserer Ordnerstrucktur nicht (richtig) mit migriert wurden.

Unsere Struktur:
/ Root
  • Kunden ORDNER
    • Verbindungen (RDP)


Auf den „Kunden Ordner“ haben wir unter 2012 unsere Persönliche Anmelde Daten gesetzt.

Nach der Migration in der 2015 DB, sind die Einstellungen auf allen Ordnern erstmal auf „Vererbt Daten“ „Keine“.
Wähle ich nun „Persönliche Date“ sehe ich die Persönliche Anmeldedaten wie in der alten DB. Ich kann nun diesen Dialog mit „OK“ oder auch mit „Abbrechen“ beendend und trotzdem bleibt die letzte Auswahl aktiv.

Im Anschluss kann ich wie gewohnt wieder arbeiten.
Ich kann leider meinen Kollegen nicht zumuten, dass sie nach der Umstellung, durch alle Ordner gehen müssen um ihre Anmeldeeinstellungen gerade zu ziehen. (Mulltiselect ist hier keine Lösung)

Sieht für mich nach einen Bug aus.

MFG
Sascha
Reply
#2
Hm, das müssen wir versuchen nachzustellen - sowie wir die Ursache haben, wird es für den nächsten Patch berücksichtigt...
Regards/Gruss
Oliver
Reply
#3
Ich kann das Verhalten so wie beschrieben nachstellen. Der nächste Schritt ist die Ursachenfindung.
Grüsse, Dirk Schäfer
Reply
#4
Danke, dann sind wir mal gespannt
Reply
#5
Ich stelle ebenfalls die selbe Problematik mit den persönlichen Anmeldeeinstellungen fest.
Unseren ca. 150 Benutzer kann ich nicht zumuten, alle Ordner (über 100) durchzugehen und die Einstellungen zu korrigieren.

Wie würde eine allfällige Korrektur dieses Problems aussehen? Müsste die DB der 2012er Version erneut migriert werden?

Grüsse
Matthias
Reply
#6
Ich versuche gerade dem Problem nachzugehen - allerdings schaffe es nicht das Fehlverhalten nachzustellen - daher muss ich nochmal nachhaken wie genau die Konfiguration vorher / nachher aussieht...

Ich habe ebenfalls die gleiche Struktur bei mir angelegt - dann auf Ordnern "persönliche Anmeldeeinstellungen" zugewiesen - mit verschiedenen Benutzern - nach der Migration haben alle Benutzer als Auswahl "Persönliche Daten" und die richtige Anmeldeeinstellung ist vorhanden...

Sind in 2012 auch Standard-Anmeldeeinstellungen hinterlegt? Gibt es spezielle Berechtigungen auf den Ordnern?
Regards/Gruss
Oliver
Reply
#7
Hallo Oliver,

wir haben das so.
Unter 2012:

Auf der obersten Ebene „Verbindungen“ haben wir unter den „Anmeldeeinstellungen“ nichts ausgewählt. Erst auf den da drunter angelegten Ordnern haben wir je nach „Kunde / Domäne“ unterschiedliche „Persönliche Anmeldeeinstellungen“ eingestellt. Jeder Kollege hat dort seine eigenen Persönlichen Einstellungen.

Eine Berechtigungsstruktur haben wir nicht eingerichtet.

Nach der Migration auf 2015 Patch 8

Auf der obersten Ebene unter „Verbindungen“ sind keine „Anmeldeeinstellungen“ gesetzt, weder unter „Standard Daten“ noch unter „Persönliche Daten“.

Auf unseren Ordner, die wir da drunter haben, sind die Einstellungen nach der Migration wie folgt:
Das auf allen Ordner die „Anmeldeeinstellungen“ auf „Vererbte Daten“ stehen. Da auf oberster Ebene dort nichts ist, ist auch auf dem Ordner nichts gesetzt, also „Keine“.

Wähle ich nun im gleichen Dialog den „Reiter“ „Persönliche Daten“ ist dort auch schon die Persönliche Anmeldeeinstellung richtig ausgewählt zb. Ordner „XYZ“ Login Daten „XYZ“, somit glaube ich auch, dass die Daten richtig migriert wurden, aber eben alle Ordner auf Default vom der obersten Ordnereben zurückgesetzt werden.

Bei Ordnern wo ich auch unter 2012 nichts hatte, ist unter 2015 auch nichts.
Die Ordner mit „Öffentlichen Anmeldeeinstellungen“ werden richtig migriert und haben auch nach der Umstellung die gleichen „Öffentlichen Anmeldeeinstellungen“

Ich hoffe, ich habe es halbwegs rüber bringen können.

Grüße
Sascha
Reply
#8
Hm, wir hatten da ein Problem, das eigentlich gelöst sein sollte - das lässt sich aber sehr leicht feststellen - einfach folgendes SQL-Statement auf der DB ausführen

DELETE FROM ItemPropertiesUsage WHERE RolePropertyId = 'DE830943-8687-4C45-AADE-1FC83C5BEDB6' AND UserId = '00000000-0000-0000-0000-000000000000'

Entweder es werden keine Einträge gelöscht - dann ist es ein neues Problem!
Oder es werden Einträge gelöscht, dann sollte das Problem damit eigentlich behoben sein!
Regards/Gruss
Oliver
Reply
#9
Auf meiner DB werden keine Records gelöscht.
Bzw. um nichts kaputt zu machen habe ich folgendes Statement ausgeführt.

SELECT * FROM ItemPropertiesUsage WHERE RolePropertyId = 'DE830943-8687-4C45-AADE-1FC83C5BEDB6' AND UserId = '00000000-0000-0000-0000-000000000000'

Dies lieferte keine Ergebnisse zurück.
Reply
#10
Gibt es schon Neuigkeiten zu diesem Thema?
Reply
#11
Hm, hatte die letzte Antwort irgendwie übersehen - sorry - wäre es denn möglich, das ich ein Datenbank-Backup (mit MSSQL Management Studio) bekomme um es mir vielleicht direkt anzusehen und die DB-Struktur dabei zu untersuchen? Wenn gewünscht können gerne vorher die Daten der Anmeldeeinstellungen unkenntlich gemacht werden...
Regards/Gruss
Oliver
Reply
#12
Also wenn es möglich ist, Backup der DB machen - Restore als neue DB - dort dann

UPDATE ItemProperties SET Data = '' WHERE RolePropertyId = '5B5AA970-E8EA-4162-BECE-6A366E150C92'

Dann nochmals ein Backup dieser DB machen und an asg.rd@asg.com schicken - oder wenn es noch zu gross die Download-Möglichkeit - bitte einen Link zu diesem Thread hinzufügen, dann geht es schneller mit der Zuordnung...
Regards/Gruss
Oliver
Reply
#13
Hallo Oliver
Hier ist der Link zum migrierten DB-Backup bei welchem ich wie oben beschrieben die PWs gelöscht habe.
--> https://goo.gl/D28qwH

Vielen Dank für deine Prüfung.
Reply
#14
Ok habe es heruntergeladen (kann wieder entfernt werden) - treten die Probleme an einer bestimmten Stelle auf? Bestimmter User?
Regards/Gruss
Oliver
Reply
#15
Hallo Oliver.

Habe dir eine PM gesendet.

Gruss

Matthias
Reply
#16
Danke Dir - und ich zurück :-)
Regards/Gruss
Oliver
Reply
#17
Hallo,
ich war kurz eine Woche weg.

Ich habe leider auch keine Änderung mit der dem SQL Befehl erreichen können.

Bei uns ist es aber auch nicht möglich, die Datenbank zu verschicken. Ich könnte nur Anbieten sich den Fehler via einer Remotsitzung anzuschauen. Einfach via PN melden bitte.

Gruss
Sascha
Reply
#18
Quote:RE: Vererbte Anmeldeeinstellungen ziehen nicht \\ Verbindungen zu WIN7-VMs instabil


Also - wir haben gerade ein Problem bei der Migration gefunden und behoben - ich weiss nicht seit wann dieser existiert, aber es deutet darauf hin, das es sich hierbei um den gleichen Fehler handelt - nämlich das die Einstellung "Persönlich" bei den Anmeldeeinstellungen falsch migriert wurde... Ich kann die Daten in der neuen Version aber nicht von bereits geänderten Daten unterscheiden - daher müsste die Migration nochmals gemacht werden oder per MultiEdit versuchen die Daten wieder zu korrigieren...

Das mit den verschachtelten Gruppen schaue ich mir mal an - es sollte eigentlich gehen, aber ich werde es nochmals testen...

Regards/Gruss
Oliver

Könnte das unsere Problem vielleicht auch lösen ?
Reply
#19
Ja, das sollte es :-)
Regards/Gruss
Oliver
Reply
#20
Hallo Oliver,

ich muss leider das Thema wieder hoch holen.
Das Update auf 2015 haben wir ausgelassen und testen nun die 2016. Der Fehler, den ich im ersten Post beschrieben habe ist dennoch unter 2015 und nun auch unter 2016 geblieben.

Wir haben bei unterschiedlichen Kollegen an Unterschiedlichen Verbindungsobjekten, dass die Anmeldeeinstellungen auf „Persönliche Daten“ stehen. Obwohl in der Original 2012 Datenbank dort „Anmeldeeinstellungen von übergeordneten Ordner erben“ ausgewählt ist.

Ich hab deshalb in der 2012 DB dann nochmal die Anmeldeeinstellung am Objekt hin und her geändert und im Anschluss die Datenbank unter 2016 migriert. Siehe da, die Anmeldeeinstellungen passen nun. Leider gilt das nur für das eine Objekt und auch nur für den Benutzer.
Scheinbar liegt der Fehler in der 2012 Datenbank was die Migration nicht abfangen kann.

Ich kann aus internen Gründen die Datenbank nicht raus geben.

Ich hoffe wir finden eine Lösung.

MFG

Sascha
Reply




Users browsing this thread: 1 Guest(s)