157 lines
7.5 KiB
Markdown
157 lines
7.5 KiB
Markdown
---
|
|
tags:
|
|
- upnote-import
|
|
---
|
|
|
|
# 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:
|
|
|
|
<br>
|
|
|
|
(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:
|
|
|
|
|
|
|
|
<br>
|
|
|
|
Wo ist das Reposiroty? Aufpassen, das Laufwerk C:\\ nicht voll läuft
|
|
|
|
<br>
|
|
<br>
|
|
<br>
|
|
<br>
|
|
|
|
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
|
|
|
|
<br>
|
|
|
|
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,
|
|
|
|
<br>
|
|
|
|
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:
|
|
|
|
<br>
|