NilsK

Moin, Ich stimme Evgenij völlig zu. Technisches Aufrüsten wird das Problem nicht lösen, sondern vor allem viel Geld kosten und die loyalen Mitarbeiter nerven. Wenn ein Mitarbeiter mit bestimmten, wichtigen Daten arbeiten muss, dann wird er auch Zugriff darauf haben. Und da in Deutschland niemand seinen Job von heute auf morgen wechselt, wird jemand, der Daten mitnehmen will, dies völlig unauffällig vorbereiten können. Man muss hier also einen sinnvollen Umgang finden. Nicht jeden Praktikanten an die kritischen Geheimnisse zu lassen, ist sinnvoll. Irgendwelche technischen Hürden aufzubauen, ist hingegen meist unsinnig. Und da gehört die Beratung hin. Gruß, Nils

Moin, Ich glaube nicht, dass Schnellschüsse hier helfen. Zunächst wäre doch mal zu klären, was überhaupt das Problem ist und wie künftig die Zugriffe geregelt werden sollen. Möglicherweise reichen ja doch recht simple Zugriffsrechte aus? Eine Planung wirst du in jedem Fall machen müssen, das nehmen dir die ganzen Tools, die du nennst, nicht ab. Gerade wenn es das Geld des Kunden ist, hat er ein Recht auf Beratung. Gruß, Nils

Moin, das heißt, Speichervorgänge von diesem Server aus auf beliebige andere Server führt unabhängig von der Anwendungssoftware zu Problemen? Dann sollte sich doch sicher was im Eventlog dazu finden, oder? Neustart schon versucht? Gibt es weitere Probleme auf dem System? Ist die Uhrzeit auf dem Server korrekt? Gruß, Nils

Moin, Deine Frage ist nachvollziehbar, aber leider so nicht zu beantworten. Um zu verstehen, was du verstehen willst, musst du nicht den Event Viewer verstehen, sondern die jeweilige Komponente, die ihre Meldungen ins Log schreibt. Ja, das kann jeweils eine sehr große Aufgabe sein. Leider wird dir faktisch nicht viel anderes übrig bleiben, als intensiv in der jeweiligen Situation zu recherchieren. Gruß, Nils

Moin, wenn du die Frage 20 Leuten stellst, wirst du mindestens 21 Antworten dazu bekommen. Die meisten davon sind plausibel, keine passt überall. Da sAMAccountName und UPN unterschiedlich sein können, der UPN das Format einer Mailadresse hat und der SAM-Name begrenzt ist, könnte man aus der Not eine Tugend machen: Den SAM-Namen unabhängig vom "echten" Namen machen und den UPN identisch zur (personenbezogenen) Mailadresse. Dann bleibt einer der Namen auch dann gleich, wenn z.B. jemand den Namen seiner Frau annimmt. Gleichzeitig kann man sich die Anmeldung an Windows und an M365 gut merken. Für den SAM-Namen sollte man dann ein Attribut nehmen, das sich im Unternehmen wirklich nicht ändert. Meist eignet sich dazu die Personalnummer. Nicht schön, aber simpel und eindeutig. Gruß, Nils

Moin, meines Wissens nicht - denn dann hat der Lizenzgeber ja keinen Vertrag mit dem Unternehmen, das die Lizenzen tatsächlich nutzt. In allen leicht zugänglichen Dokumenten heißt es deshalb "one single licensing organization" oder vergleichbar. Aber ich bin auch kein Lizenzspezi. Unabhängig davon rate ich aber dazu, das Konstrukt auch technisch-organisatorisch zu betrachten. Erfahrungsgemäß tun sich auch dabei oft Punkte auf, wegen derer man noch mal anders denken sollte. Gruß, Nils

Moin @R2D2-4dot0, nur nebenbei bemerkt: Dein eigener Ton ist auch hochgradig kritikwürdig. Vielleicht mal etwas durchatmen. Gruß, Nils

Moin, einfach so zugreifen (also die Lizenz der anderen Firma nutzen) geht nicht. Vermieten lässt die Lizenz auch nicht zu. Ein Verkauf sollte möglich sein. Ich zweifle aber, ob das mit dem Gesamtkonstrukt lizenzrechtlich funktioniert - die zugreifenden User brauchen ja auch noch Windows- und RDS-CALs. Und man darf nicht einfach so Mitarbeiter einer anderen Firma seine Systeme nutzen lassen - auch das schließen die Lizenzen aus. Hier wäre vorab eine Beratung sinnvoll, bei der das Konzept sowohl technisch als auch lizenzrechtlich geprüft wird. Nur technisch oder nur rechtlich würde vermutlich jeweils einen wichtigen Teil unberücksichtigt lassen. Ein Fall für einen kompetenten Dienstleister, würde ich sagen. Gruß, Nils

Moin, was die Kollegen meinen, aber - warum auch immer - nicht sagen: Ein "zweiter Server" in dem Sinn, wie er dir vorschwebt, wäre nicht einfach ein zweiter Server, sondern er würde zu einem recht komplexen Konstrukt gehören, das in den Bereich "Verfügbarkeit" bzw. "Hochverfügbarkeit" gehört. Allgemein bezeichnet man das als Failover Cluster, im Fall von Exchange bezeichnet man das seit einigen Jahren als Database Availability Group. Damit hättest du jetzt ein paar Stichworte, mit denen du weiterkommen solltest. Gruß, Nils

Moin, ich ergänze mal: Normalerweise sind für einen Domain Join auch gar keine AD-Adminrechte nötig. Die Vermutung wäre also, dass es gar nicht mit den Adminrechten zusammenhängt, sondern etwas anderes hakt. Andere Vermutung: Je nachdem, was du mit "am WDS-Server anmelden" meinst, könnte dir theoretisch auch UAC dazwischenfunken, denn der Builtin-Administrator wird nicht durch UAC eingeschränkt, alle anderen Administratoren hingegen schon. Das ist auch praktisch das einzige, das diesen Administrator zum "Ober-Admin" macht. (Ob das bei WDS tatsächlich einen Unterschied macht, weiß ich nicht. Ich muss zum Glück keine Clients installieren. ) Gruß, Nils

Moin, Ich muss zustimmen, ich verstehe auch kein Wort. Bitte noch mal in Ruhe erklären. Gruß, Nils

Moin, da du ja nur drei Fälle zu unterscheiden hast, reicht vielleicht ein CASE-Konstrukt aus. Eine eigene Funktion dafür kann man auch bauen, aber das erscheint mir hier zu hoch gegriffen. [CASE (Transact-SQL) - SQL Server | Microsoft Docs] https://docs.microsoft.com/de-de/sql/t-sql/language-elements/case-transact-sql?view=sql-server-ver15 Vielleicht noch eine allgemeine Anmerkung: Wie gesagt, für den Anfang ist das Vorhaben schon ziemlich komplex. Ich würde das jetzt erst mal in kleine Teile zerlegen. Für die Einsortierung in wenige Kategorien etwa wirst du im Web -zig Anregungen finden. Bau dir damit erst mal ein paar Abfragen, die die Werte nur ausgeben. Wenn du das drauf hast (da wird es vermutlich mehrere Möglichkeiten geben) gehst du weiter und schaust, welchen der Wege du in deinem Szenario gut weiter verwenden kannst. Gruß, Nils

Moin, Eine View baust du mit Create View. Auch dazu findest du das Nötige in der Doku. Dein Update geht deshalb nicht, weil die Tabelle ja keine Spalte "Alter" hat. Die hast du nur in deiner Abfrage virtuell erzeugt. Du könntest aber die Logik, die in deiner Abfrage das Alter errechnet, auch direkt in deinem Update-Statement in der Where-Klausel verwenden. Gruß, Nils

Moin, ja, "sollte" ... aber wie das dann eben in der typischen AD-Umgebung mit solchen Gruppenmitgliedschaften ist. Und ruck-zuck ist LAPS der Hebel, der dem Angreifer den Weg vom Eindringling zum Admin ermöglicht. Kann gutgehen, aber ich hab da eben so meine Zweifel, was den Umgang mit Berechtigungen im AD angeht. Gruß, Nils

Moin, ich ergreife die Gelegenheit, meine grundsätzlichen Bedenken gegen LAPS noch einmal anzubringen. Die Lösung ist sicher pfiffig, aber nur innerhalb enger Grenzen. Leider wird sie in der Praxis oft jenseits dieser Grenzen eingesetzt. Der Sicherheitsgewinn von LAPS hängt nahezu ausschließlich an den Berechtigungen für das Kennwort-Attribut im AD. Damit das funktioniert, braucht man strenge administrative Prozesse, die sinnvoll regeln, wer auf diese Kennwörter nun zugreifen darf. An der Stelle sehe ich in der Praxis Nachlässigkeiten - und schon hat man nicht mehr, sondern weniger Sicherheit, indem man Anwendern, die es eigentlich nicht können sollten, die Kennwörter auf dem Silbertablett darreicht. Und damit natürlich auch Angreifern. Und dann kommen schnell Jenseits-der-Grenze-Ideen dazu wie der Klassiker "Adminrechte temporär vergeben, indem man dem User das lokale Kennwort gibt und es gleich danach per LAPS ändert". Man kann LAPS sinnvoll einsetzen, aber das erfordert dann eine Sorgfalt, die in vielen Umgebungen nicht vorhanden ist. Gruß, Nils

Moin, indem man den Termin nicht von Montag 10 Uhr bis Mittwoch 18 Uhr laufen lässt, sondern einen Serientermin über drei Tage einrichtet: Montag bis Mittwoch jeweils 10 bis 18 Uhr. Das umgeht (meist) technische Hakeleien, und es sorgt auch für bessere Übersicht. Ganztätige Termine oder solche, die über die Tagesgrenze gehen, zeigt Outlook leider in einigen Ansichten nicht gut an, sodass man sie leicht übersieht (z.B. in der Planungsansicht). Serientermine mit Start- und Endzeit sind besser sichtbar. Insgesamt gibt es bei Kalendereinträgen aber immer wieder Probleme, besonders wenn man mit verschiedenen Clientprogrammen und mehreren Usern darauf zugreift. Manchmal kann man da nur mildern, aber nicht lösen. Gruß, Nils

Moin, dafür dass du mit SQL anscheinend noch nicht so weit bist, hast du dir ein ziemlich komplexes Szenario ausgesucht. Daher empfehle ich dir, dass du dich ranhangelst. Das würde man beim Entwickeln auch machen, wenn man schon weiter ist. Bevor du also irgendwas in die Datenbank schreibst, prüfe erst mal deine Select-Kriterien, ob sie dir in allen Fällen die richtigen Daten zurückgeben. Wenn du das hast, könntest du dir z.B. eine View in der Datenbank bauen, die dir zu jedem Kind angibt, in welche Gruppe es gehört. Ob du das Ergebnis dann überhaupt noch "fest" in eine Tabelle schreiben musst, hängt von der Logik deiner Anwendung ab. DATEDIFF könnte dabei eine hilfreiche Funktion sein; Transact-SQL kennt eine ganze Reihe von Datumsfunktionen. Das ist auch gut dokumentiert - arbeite dich also auch gleich in die Doku ein. https://docs.microsoft.com/en-us/sql/t-sql/functions/datediff-transact-sql?view=sql-server-ver15 Gruß, Nils

Moin, Ja, das ist natürlich möglich. Genau wie bei anderen Programmlōsungen musst du dir hier einen Algorithmus überlegen, der beschreibt, was du brauchst. Dann schaust du, wie du diesen umsetzt. Den Grundstock für deinen Algorithmus hat du ja schon beschreiben. Den musst du nun noch verfeinern - spontan denke ich da an sowas wie: was heißt "Sommer" genau? Wie ist und wann findet die Zuordnung statt? Usw. Zur Umsetzung: wie weit bist du in SQL denn schon gekommen? Welche ersten Ideen hättest du denn, wie du die Umsetzung angehen könntest? Gruß, Nils

Moin, Ich füge noch hinzu: kommt drauf an. Ich habe das vor Jahren mal durchdekliniert. Das meiste davon dürfte noch zutreffen. https://www.faq-o-matic.net/2016/12/19/hyper-v-von-lteren-versionen-nach-windows-server-2016-migrieren/ Gruß, Nils

Moin, Zu den konkreten Fall habe ich keine Idee, nur allgemein die Anmerkung, dass mehrtägige Termine im Outlook-Kalender sowohl organisatorisch als auch technisch oft Probleme bereiten. Ich habe gute Erfahrungen damit gemacht, stattdessen Terminserien einzutragen. Gruß, Nils

Moin, ich habe mir auch schon gedacht: [Die Liedarchäologen - Wir wollen unseren alten Kaiser Wilhelm wiederhaben] http://www.geschichte-in-liedern.de/Wir-wollen-unseren-alten-Kaiser-Wilhelm-wiederhaben/ Gruß, Nils

Moin, achott ... am Ende ist es mir egal. Ich setze halt gern auf Industriestandards und nutze gern Tools, die anerkanntermaßen richtig gut sind. Aber ist ja ein freies Land hier. Gruß, Nils

Moin, das gibt es auch schon in fertig: OldCmp von joeware.net. Das kann anzeigen, verschieben, deaktivieren - ganz nach Wunsch. [OldCmp] https://joeware.net/freetools/tools/oldcmp/index.htm Gruß, Nils

Moin, fangen wir doch mal am richtigen Ende an: Was willst du denn erreichen? Also - offenbar willst du Logondaten abfragen, aber was soll damit geschehen? Gruß, Nils

Moin, zumindest solltet ihr das kritisch betrachten. Im Effekt macht ihr die private Mailbox zu einem Teil eures Systems, könnt sie aber nicht kontrollieren. Für mich wäre das nicht okay und ich ließe mir das von einem Feelancer nicht vorgeben. Gruß, Nils