cj_berlin

Genau so habe ich es auch immer gelöst, nur halt rein mit PowerShell. Oder es gab SCCM, und dann konnte man es darüber steuern.

...aber nur, wenn die Firewall inbound geöffnet wird. Dafür muss man im Deployment dann sorgen. Alternative ist, wenn die neue Maschine selbst weiss, dass sie fertig ist, könnte sie ja outbound eine Benachrichtigung schicken...

Moin, auf DVD brennen wäre eine Möglichkeit. Ob das den Prüfer befriedigt, hängt vom Prüfer ab. EDIT: Hat das Kleinunternehmen denn bereits verbindlich herausgefunden, *welche* gesetzlichen Regelungen dafür gelten?

Schaut euch AutomatedLab von Raimund André an.

Ja, das ist so. Der maximale Renewal-Zeitraum (Default: 7 Tage) gilt aber dennoch ab der Erstasstellung.

Das Thema ist doch schon behandelt worden.

Nö. Das hat er getan, um aus Email Geld für abenteuerliche KI-Projekte zu pressen. Nichts davon ist auch nur ansatzweise barmherzig.

...außer man ist in einer Umgebung mit standardisierter C:-Größe unterwegs, und diese ist für Exchange nicht ausreichend. Exchange 2019 braucht locker 150G, mit den Performance-Mitschnitten, Logs und anderen Sachen. Ansonsten stimme ich zu, wenn man darauf achtet, die Mail Queue und die Datenbanken woanders zu platzieren, ist C: ein wunderbarer Installationsort für Exchange.

Ja. Merke gerade: Das Forum akzeptiert "Scheiß" als zulässiges Wort "b***d" und "doof" werden sonst immer gesternchent.

...wobei seit Server 2016 die Vergabe von SPNs an IP-Adressen möglich ist und respektiert wird, sofern es sich bei dem Ziel nicht um einen Domain Controller handelt. Das ist aber häßlich und sollte nicht verwendet werden. Ich kann nur ahnen, was Microsoft dazu veranlasst haben könnte, solch einen kruden Scheiß zu implementieren.

Moin, so etwas? https://www.active-directory-faq.de/2016/03/ad-lds-proxy-authentication LDS muss natürlich den User auflösen, d.h. die Domäne, in der die LDS-Instanz Mitglied ist, muss allen Domänen vertrauen, aus denen die User kommen.

Ich würde nebenbei auch noch in die Ausschreibung von der F123 schauen. Eventuell ist da die Verpflichtung zur Nachlieferung drin, wie man es in einer besseren Welt erwarten würde. Und dann wandert das Problem dorthin, wo es hingehört, ohne übermäßig hohe Kosten für den Steuerzahler EDIT: Die Specs sind ja da, ich kann mir nicht vorstellen, dass die Erstellung eines Diskettenlaufwerks oder des Mediums ein verloren gegangenes okkultes Wissen darstellt... Aber ich bin halt ein Idealist - natürlich wurde jedweder After-Sales-Support dort ausgeschlossen, wie bei jeder Public-Private-Partnership. Drum halten einige Parteien die PPPs ja auch heute noch für ein Erfolgsmodell.

Naja, im letzten Jahrhundert konnte ja wirklich niemand ahnen, dass man sich mit einer Branche ins Bett legt, die vom Consumer-Verhalten getrieben wird. Es sind halt ganz andere Produktzyklen - die TU-95 und die B-52 werden, wenn der Plan aufgeht, fast 100 Jahre im Dienst gewesen sein. In der IT indes unterstützt Apple eigene Produkte nicht mehr, die vor fünf Jahren vom Stapel gelaufen sind. Da prallen halt Welten aufeinander. In Aerospace ist es üblich, die gesamte Entwicklungsstrecke eines Produkts bis zu dessen Verglühen bei Wiedereintritt zu konservieren. Da können gut und gern 20-30 Jahre vergehen. Weiß jemand, ob man dann noch USB-A und RJ-45-Stecker findet, falls mal Ersatzteile benötigt werden? Nein, das weiß kein Mensch. Will sagen, vielleicht sind "unsere" Produktzyklen zu kurz und nicht die anderen zu lang?

Moin, der RDP-Client läuft im Kontext des Users. Du kannst ihm kaum verbieten, einen Prozess, den er gestartet hat, zu beenden. Insofern, selbst wenn Du den X-Button irgendwie weg operiert bekommst, bleibt immer noch taskkill

Moin, Du meinst vermutlich VAMT? Das ist Teil des Windows ADK: Install VAMT - Windows Deployment | Microsoft Learn

Hmmm. Ich sehe den Download.

$schemaNC = ([ADSI]"LDAP://RootDSE").schemaNamingContext[0] $dS = New-Object System.DirectoryServices.DirectorySearcher $ds.SearchRoot = New-Object System.DirectoryServices.DirectoryEntry(('LDAP://{0}' -f $schemaNC)) $ds.SearchScope = [System.DirectoryServices.SearchScope]::Subtree $ds.Filter = '(&(objectClass=attributeSchema)(isMemberOfPartialAttributeSet=TRUE))' $null = $ds.PropertiesToLoad.Add('name') $ds.FindAll().ForEach({$_.Properties['name'][0]})

Moin, nur um ganz sicher zu gehen: Die Einträge haben auch ein Ablaufdatum? Worauf ist Refresh und NoRefresh eingestellt?

How to Seize a FSMO Role with NTDSUtil (briandesmond.com)

Moin, nein, diesen Unterschied hat es als funktionalen Unterschied nicht gegeben. Kann der User sich über RDP anmelden, wenn Du ihn in die lokalen Admins steckst? Kann ein anderer User, der Mitglied in "Remote Desktop Users" ist, sich über RDP anmelden?

Ja

Moin @wznutzer, vielleicht merkst Du es schon: Die ultimative Antwort auf Deine Herausforderung wäre ein Web-Frontend für das ERP, idealerweise mit MFA. Dann musst Du niemanden in Dein Netz lassen, und das Thema ist erledigt. Vielleicht kann der Anbieter der ERP-Software so etwas ermöglichen, zumindest für den Teil der Arbeit, welcher an Externe rausgegeben wird? Ist es nicht möglich, dann hast Du User, die sich in Deinem Netz anmelden und deren Credentials theoretisch abhanden kommen könnten. Und an dieser Stelle gibt es keine Empirik, die nahelegt, dass Externe dort weniger Sorgfalt an den Tag legen würden als Interne, eher im Gegenteil. Somit musst Du für jeden User, intern wie extern, eine Blast Radius-Analyse betreiben und die Angriffsfläche entsprechend einschränken. Da sprechen wir aber nicht primär über IP-Adressen und Ports, sondern über Berechtigungen. Für IP-Adressen und Ports gibt es zwar auch einige leicht umzusetzende Vorschläge, welchje die Sicherheit erhöhen (Clients dürfen nicht miteinander sprechen, Client-, Drucker- und VPN-Netze dürfen nicht in Management-Netze sprechen usw.) aber das ist unabhängig von diesem Thread. Mein Lieblingsbeispiel: Es gibt NULL Notwendigkeit für Otto Normaluser, egal ob kaufmännisch gesehen intern oder extern, Admin-Accounts, Admin-Gruppen oder Computer-Objekte per LDAP im AD zu lesen. Betrachtet man es genauer, ist es in 95% der Fälle für Otto Normaluser nicht notwendig, IRGENDEIN AD-Objekt aus der Domain-Partition außer dem eigenen User-Objekt zu lesen. Und wenn man das verinnerlicht hat und sich dann den Schreibrechten zuwendet, kann man weiter härten Druckspooler überall deaktivieren, wo nicht gedruckt wird. EDIT: Auf Tier 0-Systemen auch dann, wenn dort gedfdruckt wird, und das Drucken von dort entfernen. Wie, ist egal. Alle Webdienste aus dem Repertoire von ADCS rigoros deinstallieren, bis auf HTTP-CDP und OCSP. Last but not least: Ich weiß nicht, ob die Vertragslage sich geändert hat, aber früher war es nicht ohne weiteres zulässig, Personen auf seiner Windows-/SQL-Infrastruktur dauerhaft arbeiten zu lassen, die wirtschaftlich nicht zu dem Lizenznehmer-Unternehmen gehören. Vielleicht kann @lizenzdoc das auch noch bewerten.

Das nicht, aber ich kenne einige, die länger benötigen würden, das optimierte Skript zu entwickeln, als die Laufzeit des unoptimierten gewesen wäre

Musst Du nicht. Viele haben sich die Arbeit bereits gemacht, hier ein Beispiel: Selbst wenn das der einzige Vorteil wäre, wäre es in vielen Situationen ein enormer Vorteil Beispiel: Information aus dem AD wird in einem Login-Skript benötigt. Installierst Du dann auf 10.000 Clients AD-RSAT?

Du hast aber auch den Anfang der PURE-Seite gelesen, gell? Die einzige Situation, wo es wirklich ars***rettend ist zu wissen, wie man Dinge ausschließlich mit PowerShell-Cmdlets löst, tritt dann ein, wenn Du dich als Skripter plötzlich unter Constrained Language Mode wiederfindest. An der interaktiven Kommandozeile ist es in der Regel auch einfacher, Cmdlets als .NET-Klassen zu verwenden. Beim Skripten jedoch spielen andere Faktoren eine Rolle: Performance und ihre Komplementärdisziplin, der Ressourcenverbrauch Portabilität Robustheit und da ist man gut beraten, die dem ganzen zugrundeliegenden .NET-Techniken zu beherrschen.