7.5 KiB
| tags | |
|---|---|
|
Austausch zu Desktop Central
neue Installation nicht nötigt, Remote-Offices und Konfigurationen können zurückgesetzt werden
Update-Prozess
nur Dienst start Sop und Update-Manager
Problem: serverinstanz wird aktualisiert → agends aktualisieren sich automatisch
Geräte nicht verbunden: Mutterschutz → mehrere Version upgedatet → führt zu Problkeme, Agend muss dann neu installiert werden
Home-Office Geräte sollten auch ohne VPN erreichbar sein
Vorteil gegenüber WSUS
Firewall-Konfiguration und Zertifikat prüfen
Agnet → Computers
Agend-Versionen aktuell halten
Agend über Gruppenrichtlinie ausrollen
→ Agend in GPO muss regelmäßig ausgetauscht werden
"Drüberbügeln" nicht möglich, weil Installation nicht als Update erkannt wird
in internal.lan wird Agend noch nicht verteilt
Tipp: bei Suche nicht den LoggedOn User, sondern den LastLoggedOn User verwenden
Remote-Offices:
Standorte Trennen
Netztrennung
IP-Scode
besonders Interessant für Mobile Geräte
Beispiel: Notebook in Produktion → neue IP → IP Ordnet sich dem Remote-Office zu
→ Welcher MA arbeitet aktuell an welchem Standort
VLAN Produktion
Jedes Remote-Office hat einen eigenen Agenten
Installationsdatei für Produktion
Default Remote Office ist ein WAN
Anwendungsbeispiel: Steuern, an welche Standort welche Remote-Server (Sattelit) genutzt werden soll
Zuordnung ändern:
IP-Scopes: neutrales Remote-Office, aus dem die Installationsdatei immer verwendet werden kann
neue Geräte aus dem CLM → Landen zunächst im Default -Remote Office
Zuweisung in korrekte RO erfolgt dann später über die IP-Scopes
Admin → Global Settings → Custom Groups
Static vs. Static Unique vs dynamic
Dynamic am häufigsten genutzt → Vorschau möglich
Client-Betriebssysteme von Server-Betriebssystemen trennen
Dritte Möglichkeit über Domänen-OUs
Konfiguration des Patch-Dashboards: → Charts grün machen
entscheidendere Kennzahl:
(Manual Update Required) → Dentop Central DB hat dann keinen Zugriff auf die Binaries
Remote Desktop Manager → Problemfall aus der Vergangenheit, nach der erste Ausgerollt war, mussten alle anderen auf das Update warten, um es nutzen zu können.
Lösung: Update per Self-Service bereitstellen:
Wo ist das Reposiroty? Aufpassen, das Laufwerk C:\ nicht voll läuft
Problem: Entweder ewig laufende Configuration, oder über Deploymentprozess eines neues Systems automatisch festlegen
Was es nicht gibt: Installation läuft immer als passiver Dienst, Produktivität des Mitarbeiter steht an erster Stelle, MA wird nicht unterbrochen, Office wird nicht geschlossen, → Fehler Application in Use by User
Hees im Kundenumfled: alles anhaken
ggf. trennen, Security Updates täglich
Third Party immer alles anhaken ist empfohlen
Software die nie mehr aktualisiert wird → Patch declien, damit die Bewertungsskala korrigiert wird → Das Nicht-Patchen ist dann ausdrücklich erwünscht
Guter Erfahrungswert sind 3 Tage "Deploy patches after" day from release
Best practice für start:
- welche Software sollte nicht automatisch verteilt werden, z.B. Remote Desktiop Manager
- Test-Gruppe um Key-User erweitern, die nicht in der IT sind
- Server-Updates → JA
- Infrastruktur in Clients und Server aufteilen
- Dynaische gruppen bauen → Client-Betriebssystemne v.s Server-Betriebssysteme
- Client updates → ein einziger Job, eine Policy,
zweite Platte für Server konfigurieren und Repository umzuiehen (Movin Patch-Store Location)
300 GB könmnten grob geschätzt für uns passend sein
Empfohule Policy "Reboot Policy":
Für Server predeployment reboot mit einbauen
Fehlegung, wann die Server neu starten sollen:
