Persönliche Anmeldeeinstellungen werden auf Ordner nicht „richtig“ migriert.

[DevOma]

Ich versuche bis morgen ein paar SQL-Statements zusammen zu stellen - ich muss herausfinden, welche Daten in der DB diesen Fehler verursachen...

[DevOma]

So, habe eben nochmal Migrationen von 2012 auf 2016 durchprobiert - läuft immer genau wie es sein soll.

Deswegen brauche ich jetzt ein paar Daten aus der DB, mit denen ich vielleicht das Problem eingrenzen kann

SELECT * FROM vRDCredPlaces WHERE UserN = '***' and HostId in (SELECT Id FROM vRDConnections WHERE ConnectionName = '***')
SELECT * FROM vRDCredPlaces WHERE UserN = '***' and HostId in (SELECT Id FROM vRDFolders WHERE Name = '***')

Die *** müssen jeweils ersetzt warden

=> UserN = '***' sollte mit einem Usernamen getauscht warden, bei dem die Daten nach der Migration nicht mehr ok sind (steht z.B. in der Status-Leiste wenn der Benutzer mit der Applikation arbeitet - ich denke user@domain)
=> ConnectionName = '' sollte entsprechend dem Namen einer Verbindung gesetzt warden, die nach der Migration das Problem ausweist
=> Name = '' sollte entsprechend dem übergeordneten Order-Namen gesetzt warden (von der Verbindung aus dem 1. Statement)

Bitte die Daten an mich senden - gerne auch per PrivateMessage oder per Mail an asg.rd@com - dann bitte einen Link zum Thread hinzufügen, dann bekomme ich es schneller...

[derjani]

Hallo Oliver,

ich habe soeben eine Mail rausgeschickt.

MFG
Sascha

[DevOma]

Ich habe die Mail bekommen - werde aber erst Anfang nächster Woche dazu kommen, es mir nochmal genauer anzuschauen - ich melde mich...

[DevOma]

So, habe mir die Bilder eben nochmal angeschaut - vielleicht habe ich es schon mal gefragt, aber wenn ich es mir so anschaue, dann denke ich ist das Ergebnis doch richtig. Ich habe den Thread auch nochmal von Anfang an gelesen und die initiale Beschreibung past irgendwie nicht zu den Bildern...

Eine Frage zum Bild 4 - das spiegelt die Verbindung - wurde der Klick auf "Standard Daten" manuell gemacht oder ist das wirklich die Einstellung die nach der Migration als aktiv angezeigt wird - denn wenn Standard-Daten nicht vorhanden sind, sollte immer "Vererbte Daten" aktiv sein - und dann wäre es doch richtig, da die "persönlichen Anmeldeeinstellungen" auf dem Ordner gemacht wurden - "Vererbt" sollte somit aktiv sein!

[derjani]

Hallo Oliver,

du hast Recht. Das Problem hat sich seit dem ersten Post etwas verändert.

Scheinbar hat ein Update in der 2015er das Problem „etwas“ behoben :-)

Hier das Problem, dass wir weiterhin haben.

Nach der Migration von der 2012 Datenbank auf die 2016 werden die Anmeldeeinstellung auf „unterschiedlichen“ Verbindungsobjekten und bei Unterschiedlichen Benutzer durcheinander gewürfelt.
Unter 2012 haben die Kollegen auf den Kunden Ordner ihre Persönliche Anmeldeeinstellungen gesetzt. Die darunter liegenden Verbindungsobjekte bekommen nun ihre Anmeldeeinstellungen Vererbt. (Bild 1 und Bild 2)

Soweit so gut.

Nun kommt es nach der Migration der DB zu folgenden Problem:

Im Beispiel der Mail (Bild 1 und Bild 2) kontrollieren wir die Anmeldeeinstellungen auf dem Kunden Ordner „DMZ“ (Bild 3), wie zu erwarten OK. Aber auf dem Untergeordneten Objekt, sind die Anmeldeeinstellungen auf „Standard Daten“ gesetzt. (Bild 4). Dies ist leider nicht richtig!
Wiederum andere untergeordnete Objekt in dem gleichen Ordner haben die Richtigen Vererbte Anmeldeeinstellungen. (Ich hoffe du kannst mir folgen )

Wir haben also bei Unterschiedlichen Benutzern an Unterschiedlichen Verbindungsobjekten unterschiedliche Anmeldeeinstellungen. Zu erwarten ist in „Vererbte Daten“. Gesetzt ist aber „Standard Daten“ oder auch „Persönliche Daten“ mit der Auswahl „Keine“.


Meiner Vermutung:

Die Benutzer haben in der 2012 Datenbank bei den Objekten schon mal was geändert. Deshalb haben die dort in der DB einen Eintrag:

Code:

SELECT     vRDCredPlaces.UserN, vRDCredPlaces.HostId, vRDCredPlaces.CredId, vRDCredPlaces.CredUsage, vRDConnections.ConnectionName
FROM         vRDCredPlaces INNER JOIN
                      vRDConnections ON vRDCredPlaces.HostId = vRDConnections.Id
WHERE     (vRDCredPlaces.UserN = N'test@test.local')
ORDER BY vRDConnections.ConnectionName

Code:

test@test.local    4591    0    1    PC 1
test@test.local    4766    0    -1    PC 2
test@test.local    4767    0    -1    PC 3
test@test.local    5204    0    -1    PC 4
test@test.local    5205    0    -1    PC 5
test@test.local    2231    0    -1    PC 6
test@test.local    3559    0    -1    PC 7
test@test.local    6102    0    -1    PC 8
test@test.local    5834    0    -1    PC 9
test@test.local    3487    0    -1    PC 10
test@test.local    3485    0    -1    PC 11
test@test.local    3486    0    -1    PC 12
test@test.local    5850    0    -1    PC 13
test@test.local    5764    0    -1    PC 14
test@test.local    2155    5655    0    PC 15
test@test.local    2156    5655    0    PC 16

ID 2155 und 2156 ist OK dort hat der Benutzer gezielt andere Anmeldedaten gesetzt. Die Anderen Einträge sind doch Theoretisch nicht notwendig?

Aber bei den Anderen kommt es nun nach der Migration zu den oben genannten Problemen. Aber auch nicht bei allen Objekten !
Ich konnte leider nicht herausbekommen wovon es nun abhängig ist ob der Fehler zustande kommt oder nicht.

MFG

Sascha

[DevOma]

Ich versuche morgen eine DB entsprechend zu gestalten :-) Hoffe ich kann es nachstellen - das beheben ist meist das kleinste Problem :-)

[derjani]

Ich kann gerne auch ne Remote Session via Teamviewer anbieten.

MFG
Sascha

[DevOma]

Remote Session bringt mir nicht viel - ich habe hier "anscheinend" die gleichen Daten in meiner DB - aber egal was ich mache, es kommt immer das richtige Ergebnis raus.

Mich wundert vor allem, das das Problem bei keinem anderen aufgetaucht ist :-) Aber manchmal ist das eben so...

Der Vorschlag in der Mail gewisse Einträge zu löschen

WHERE (CredId = 0) AND (CredUsage = - 1)

WHERE (CredId = 0) AND (CredUsage = 1)

Wenn es hilft - vielleicht wirklich einfach so machen - die Kombinationen sind gleich mit dem "Default"-Zustand - also wenn keine Standard-Daten und keine persönlichen Daten vorhanden, dann benutze die vererbten... Es dürfte beim Löschen dieser Daten keine Veränderung geben und wenn damit das Problem gelöst wäre... Super :-)

[derjani]

Hallo Oliver,

gut dann machen wir dies erst so.

Danke für die Mühe

MFG

Sascha

[kleinerhobbit]

Guten Tag zusammen

Ich hänge mich hier gerne in den Thread rein, da ich die selbe Problematik mit der 2016er Version ebenfalls feststelle.

@Oliver: Wir waren doch bei der 2015er Version wegen der genau gleichen Problematik bereits in Kontakt und ihr konntet in dieser Version das Problem lösen.

[DevOma]

Wir hatten damals ein SQL-Script laufen lassen, das bei fast allen zum gewünschten Ergebnis führte - bis auf "derjani" - da blieb das Problem bestehen.

Nach wie vor gilt das Angebot - wenn ich eine Datenbank zum Nachstellen bekomme, kann ich den Fehler wahrscheinlich schnell eingrenzen