cj_berlin

vor 6 Minuten schrieb Dutch_OnE:

 Da eine der beiden VMs, sowie das Host System sehr viel Leerlauf haben, sollte sich das Sharing gut aufteilen und zu keinen Leistungsproblemen führen. 

Achtung! Genau das ist (nicht in Deinem Lab natürlich, in der realen Welt) der Trugschluss, dem mit am häufigsten aufgesessen wird. Wenn Du zwei VMs auf einem Host hast, und jede von ihnen hat so viele vCPUs wie der Host Hyperthreading-Kerne hat (*), und die VMs sind im Hypervisor gleich gewichtet, bekommt jede VM exakt 50% der CPU-Zeit, ganz gleich, wieviel die andere VM zu tun hat. Es kann aber durchaus ausreichend sein und im Betrieb nicht auffallen. 

Ist also von vornherein bekannt, dass eine VM CPU-mäßig mehr zu tun hat als die andere, kann es sich lohnen, die VMs zu gewichten. Das muss man aber akribisch dokumentieren und auch bei der Ressourcenplanung  für die Weiterentwicklung der Plattform berücksichtigen.

(*) genauer gesagt, VM1.ProcessorCount + VM2.ProcessorCount > Host.HTCoreCount so dass nicht beide VMs gleichzeitig CPU kriegen können.

vor 1 Stunde schrieb Dutch_OnE:

 

oder gibt das mit Überbuchung Probleme?

Probleme mit der CPU-Überbuchung sind solange subjektiv wie Du für die VMs keine SLA zu erfüllen hast. Aber das typische Überbuchungsverhalten bei CPU sieht wie folgt aus:

• kaum CPU-Verbrauch laut Task-Manager am Host
• kaum CPU-Verbrauch laut Task-Manager im Gast
• und trotzdem ist die Performance im Gast ungenügend.

Du kannst es auch messen, es gibt einen Perfmon-Counter namens "Hyper-V Hypervisor Virtual processor\CPU Wait time per dispatch" in Nanosekunden. Solange das nicht in Richtung halbe Millisekunde tendiert, sondern unter 200.000 bleibt, sollte alles soweit in Ordnung sein, zumindest aus Sicht der VMs...

Und da es keine Möglichkeit gibt, den Host-Bedarf an CPU zu reservieren, kann es passieren, dass CPU-Überbuchungsprobleme sich zuerst als wahrgenommene Storage- oder Netzwerkprobleme äußern.

vor 13 Minuten schrieb Dutch_OnE:

 

Den Exchange sollte ich auf jeden Fall noch in eine DMZ packen

Das kannst Du nicht, zumindest keinen Mailbox-Server. Exchange muss ungehinderten Zugang zu mindestens einem schreibbaren Domain Controller haben, der in der gleichen AD-Site steht.

vor 15 Minuten schrieb Dutch_OnE:

 

Kann man im Active Sync für ein Postfach nur bestimmt Mobilgeräte zulassen?

Stichwort: Quarantäne.

vor 16 Minuten schrieb Dutch_OnE:

 

Kann man OWA via Exchange Shell komplett deaktivieren?

Nein, dann funktioniert ECP nicht mehr. Du kannst OWA aber für alle Postfächer deaktivieren.

vor 8 Minuten schrieb Hajo2004:

Habt ihr da Tips wie man das angehen kann ohne AzureAD.

Du hast zwei Anforderungen formuliert, die sich gegenseitig ausschließen:

1. Internet + VPN --> es wird also eine Identität benötigt, um eine Verbindung zum AD herzustellen, ob nun alt oder neu.
2. OS platt machen --> damit beraubst Du die Maschine erst mal ihrer Identität, und die Katze beißt sich in den Schwanz.

Im LAN geht das, denn da kannst Du im Betankungsnetz 802.1X abschalten, und eine Maschine ohne bekannte Identität kann mit dem AD sprechen.

Ansätze wären:

1. Du verzichtest aufs Plattmachen --> dann können AD-Migrationstools, die diesen Namen verdienen, auch einen Domänenwechsel über VPN durchführen. Bereinigen kann man manchmal auch ohne Plattmachen. Du musst aber irgendwas erfinden, um zu inventarisieren, was denn da alles installiert und konfiguriert ist.
2. Du holst die Geräte rein --> siehe "im LAN geht das".
3. Du bastelst Dir einen USB-Bootstick, der bereits für jede Maschine ein Zertifikat inklusive Private Key und eine Offline AD Join-Datei enthält. Diesen schickst Du natürlich nicht an die User, sondern fährst von einem zum nächsten und installierst die Geräte neu. Mit dem Offline Join und dem eingespielten Zertifikat können sie eine AlwaysOn VPN-Verbindung aufbauen und kommen wieder mit der Infrastruktur in Kontakt. ACHTUNG! Dies ist keine Empfehlung, sondern einfach etwas, was technisch machbar ist.

vor 1 Minute schrieb NorbertFe:

Aber für die Aussage müßte man auch mehr Infos vom ist,/soll und Perspektive haben. Ansonsten erstmal nur ein educated guess. 

Sehe ich in diesem Fall anders. Die drei wichtigsten Punkte wurden ja bereits geliefert:

1. die vorhandene on-prem-Umgebung soll weg und ersetzt durch etwas, was es noch nicht gibt (kein Investitionsschutz also)
2. Clients hüpfen die meiste Zeit im Internet herum (auf VPN und lokaler AD-Mitgliedschaft basierende Konzepte sind also schon mal aus Security-Sicht nicht das Gelbe vom Ei)
3. Es sind nur 100x Clients, jede größere Investition in (Infrastruktur + Arbeitszeit + Lernen) ist also vermutlich pro Stück zu teuer. Und insbesondere SCCM ist *immer* eine größere Investition.

Und ich bin weiß G'tt kein "Cloud-First-CoolAid-Trinker".

Moin,

Betriebssystem-Betankung übers Internet kannst Du knicken. Auch das Sichern und Zurückspielen von Benutzerprofilen übers Internet kannst Du knicken. Wenn Du das ganze rein on-prem abwickeln willst, müssen die Leute oder zumindest die Geräte für einen Tag reinkommen.

Was Du hingegen machen kannst - entsprechende Lizenzierung vorausgesetzt - ist vorher schon die "Well Known Folders" auf OneDrive umstellen und die Geräte ins Azure AD aufnehmen statt ins AD. Dann schickst Du jedem User einen USB-Stick zu, von dem er bootet. Daraufhin wird sein Rechner plattgemacht und anschließend ins Azure AD und Intune eingerollt. Das entsprechende Image musst Du natürlich vorbereiten, kann man im Zweifel mit MDT machen. Dann meldet sich der User mit seinem Azure AD Account an, hat dann "sein" OneDrive gleich verbunden, und da liegen auch schon seine Daten. Aber das wäre ein ganz anderes Projekt, als was Dir so vorschwebt. Lohnt sich langfristig aber vermutlich mehr.

Moin,

die interessentere Frage ist ja, was übernommen werden soll. Grundsätzlich ist für die Neubetankung und Aufnahme in die neue Domäne ja egal, ob die Maschine vorher in der alten Domäne Mitglied war. Und die Clients sauber aus der alten Domäne zu nehmen, ist doch allenfalls Kosmetik.

Sollen Benutzerprofile gerettet werden? Oder gar irgendwelche Datenbestände, die außerhalb der Benutzerprofile auf den Maschinen gespeichert sind?

vor 42 Minuten schrieb GTRDRIVER:

Wie mache ich es dann richtig ?

In meiner Welt: So wie bisher, mit einer Ergänzung: Niemals etwas händisch konfigurieren, sondern jeden Schritt skripten. Dann hast Du, wenn bespielsweise ein Update oder ein Virus Deinen Server zerschießt, eine verlässliche Möglichkeit, ihn wiederherzustellen. Am Anfang ist die Lernkurve etwas steiler, aber am Ende hast Du etwas in der Hand und hast auch noch was gelernt dabei.

Und ein Wort der Warnung: Je nachdem, was da installiert und konfiguriert ist, wird ein In-Place-Upgrade möglicherweise auch mit einer Vollversion scheitern.

Moin,

wenn Du Rechte zuweist, kannst Du ja angeben, auf was sie sich beziehen. In Deinem Fall wäre vermutlich so etwas wie "Unterordner und Dateien" der richtige Scope...

Moin,

OK, das wäre dann in Ordnung. Der Klassiker ist, Admin1 installiert und Admin2 möchte administrieren, hat aber natürlich die ganzen Server noch nicht im Server-Manager.

Dann ist es vermutlich dieses Update-Problem, das uns fast das ganze Jahr 2022 verfolgt hat. Das gibt es IIRC seit März oder April, hat aber interessanterweise nicht alle betroffen. Aber das mit der Datenbank ist ein interessanter Hinweis. Vielleicht kannst Du mal versuchen, zur DB zu verbinden und zu schauen, ob man da in den Logs was sieht. Aber ich meine, es gab damals keinen wirklichen Fix außer die Farm neu bauen, oder er ist an mir vorbeigegangen. Allerdings soll es im Juni-CU gefixt worden sein...

Hmmm.

Moin,

es müssen alle am RDS beteiligten Server dem Server-Manager hinzugefügt werden. Das ist es, was die Meldung besagt. Es reicht nicht, dass man am Broker angemeldet ist und nur der Broker im Server-Manager verwaltet wird!

Moin,

Port 135 ist der Einstieg in alles, was RPC ist.

vor 8 Minuten schrieb Vitel:

beim Versuch den nächsten Client aufzunehmen war hier kein Drucken möglich und es konnte eben beobachtet werden, dass es keinerlei Kommuniktion über 445 gab und nur über 135.

Weiß der nächste Client denn, dass ihr NetBIOS bei euch im Netz deaktiviert habt? Scheint, als hätte er das Memo nicht erhalten  

Moin,

135 ist der RPC-Endpointmapper und 445 ist SMB, also File &Print. Ich würde erwarten, dass alle Clients zu irgendeinem Zeitpunt auf 135, 139 und 445/tcp sowie 137 und 138/udp mit dem Printserver kommunizieren.

vor 32 Minuten schrieb Nobbyaushb:

Das Tool von Steve (und ein paar anderen) ist zwar super aber seitens MS meines Wissens nicht supportet

da es die Cmdlets aus dem RecipientManagement-Snapin verwendet, gibt es da nichts, was nicht supportet sein könnte.

Moin,

9 von 10 Mal, dass ich das Verhalten (außerhalb groß angelegter Migrationen, wo das normal ist) gesehen habe, war das ARP Caching auf Switchen oder Routern die Ursache.

Off Topic: "Runder Kreis" finde ich sehr treffend beschrieben  

Moin,

per Default versucht Windows immer, ein Volume in RW zu mounten. NTFS und ReFS erlauben aber nur eine gleichzeitige Sperre. Du musst auf dem Backup-Server automount abschalten und das Volume in RO mounten. Dann wird es nicht gesperrt, und Du solltest lesen können. 

Automount abschalten: mountvol /N

Alles andere in DiskPart (ATTRIBUTE VOLUME SET READONLY)

vor 9 Stunden schrieb da_flo:

und am besten die Backup Infrastruktur in einer eigenen Domäne.

Du meinst sicherlich "in einem eigenen Forest". Doch wozu sollte die Backup-Infrastruktur überhaupt in *irgendeiner* Domäne sein? Gibt es dadurch echte Benefits? Je nach Umgebung, wäre es ja sogar ohne Mandantenforests schon der siebente oder gar achte AD-Forest, und langsam muss man schon anfängen, jeden zusätzlichen Forest zu hinterfragen. 

vor 32 Minuten schrieb daabm:

Kennwortwechsel sind ein absolut veraltetes Prinzip aus dem vergangenen Jahrtausend. Sogar das BSI hat sich von der Empfehlung verabschiedet.

...jedoch nur, wenn NTLM und RC4 für die betroffenen Accounts abgeschaltet sind. Andernfalls ist Kennwortwechsel nach wie vor das einzige wirklich wirksame Mittel gegen Pass-the-Hash.

CIS-Benchmarks, selbst die STIG-Variante, fordern den Wechsel nach spätestens einem Jahr.

Moin,

du *darfst* sie verwenden, aber du wirst es vermutlich nich *können*, denn 2022er CALs können nur auf einem 2022er Lizenzserver installiert werden. Manchmal habe ich es allerdings schon erlebt, dass die Keys tatsächlich funktioniert haben. Versuch Dein Glück.

vor 11 Minuten schrieb Sunny61:

@cj_berlin

Einspruch, aber der SQL Server Version 2012 (11.x) fehlt der Level 80 in der Aufstellung, beim SQL Server 2008R2 steht die 80 noch bei den Supported compatibility level values mit drin. ;)

Ja, drum mache ich auch immer bei Tabellen alternierende Zeilenfarben  Ich korrigiere das mal.

vor 1 Stunde schrieb Tossi65:

nein nicht ganz.

Ein Stück weit aber schon  Wenn Du dir die Tabelle am Anfang des verlinkten Artikels anschaust, wirst Du merken, dass bereits SQL Server 2008R2 2012 den Level 80 nicht mehr unterstützt hat.

Und weiter im Text:

Discontinued functionality introduced in a given SQL Server version is not protected by compatibility level. 

Breaking changes introduced in a given SQL Server version may not be protected by compatibility level.

Bedeutet im Betrieb soviel, dass, wenn Deine Applikation Dinge verwendet, die aus der Engine bereits herausgealtert sind, auch der Compatibility Level sie nicht zurückbringt. Sprich: Harte Inkompatibilitäten würdest Du bereits lange bemerkt haben, weil Deine Anwendungen Queries absetzen würden, die der Server nicht mehr kennt.

Die andere Auswirkung des CL ist die Query Optimization, und da musst Du in der Regel nichts machen. Oder Du lässt tatsächlich den Query Tuning Assistant durchlaufen, und da kann es sein, dass es neuere Funktionalität gibt - es kann aber auch sein, dass das DB-Schema von Anfang an nicht optimal war.

ADD: Was immer Du mit "Datenbank reinkopiert und fertig" technisch meinst, der beste Weg, eine SQL-Datenbank zu transferieren, ist Backup/Restore. So gehen beispielsweise auch dbatools vor.

Ja, so würde ich das auch sehen.

Nice