wznutzer

Das liest man sehr oft. Meine Erfahrung ist jedoch eine andere. Ein Backup vom Host ist bei mir (Veeam Agent) in unter 15 Minuten wiederhergestellt (ohne Bootzeit, 10 GB vom NAS). Natürlich alles vorbereitet (Stick usw.). Das schaffe, ich jedenfalls, nicht mit einer Neuinstallation (Treiber, Windows-Updates, Software für's Netzwerk, Raid, hier an einer Schraube drehen und dort auch noch). In Umgebungen in denen alles gescriptet, geimaged ist mag das anders sein, da kenne ich mich nicht aus. Aber das wird dann nicht die "1 - 3 Server im Keller" Umgebung sein. Die Treiber-Injection bei Veeam Agent hat bei mir noch nie funktioniert. Egal ob Server, Einfach-PC, Notebook usw.. Hinterher bootet das Ding einfach nicht mehr. Da ich aber spezifische Backups habe, ist das auch egal.

Das hatte ich bei meinem Lenovo P72 auch. Ich habe den Intel Management Driver im Gerätemanager gelöscht (inkl. Checkbox Dateien löschen). Nach einem Neustart hat sich Windows den Treiber dann aktuell über WU geladen ==> Fehler weg. Das manuelle Installieren hat den Fehler allerdings nicht behoben, nur der Weg mit löschen.

Das wars. Per Gruppenrichtlinie deaktiviert, Warnung weg. Die alte Url zeigt ja auf den internen Namen des Exchange. Die Auflösung des internen Exchange Names zu verhindern, habe ich mich jetzt nicht wirklich getraut . Danke

Die URLs sind korrekt. Das habe ich wirklich schon mehrfach geprüft und auch an CAS und Outlook Anywhere gedacht. Das Split-DNS ist auch korrekt. Es gibt zwei zusätzliche Zonen einmal ex.domain.de und autodiscover.domain.de. Als Host ist in den Zonen jeweils der Exchange drin. Getestet mit nslookup: die Domains werden korrekt aufgelöst. Mit nbtstat -a 192.168.X.X wird der interne Name des Exchange ausgegeben. Das müsste OK sein, weil es kein Reverse-Lookup für die externen Namen gibt. Bei einer Neukonfiguration des Profils stimmt dann auch alles. Die Zertifikatsmeldung kommt auch erst nach ca. 2 Minuten. Outlook ist ganz normal nutzbar. Im Verbindungsstatus wird vor und nach der Meldung nichts anderes angezeigt. Trotzdem macht Outlook noch irgendwas mit dem alten Namen und zeigt das aber nicht im Verbindungsstatus an. Ich kann die Verbindung im ProcessMonitor sehen, aber halt nicht die URL.

Hallo, W2K12 R2, Exchange CU12, Outlook 2016, jeweils alle aktuellen Updates. Der Exchange hat ein öffentliches Zertifikat erhalten. Alles funktioniert problemlos, nur Outlook beschwert sich pro Sitzung einmalig, dass das Zertifikat nicht zum Verbindungsnamen passt. Das Zertifikat ist auf den externen Namen ausgestellt, Outlook verbindet sich aber noch mit dem alten Namen. Der Meldung erscheint erst nach ca. 2 Minuten (nach dem Start von Outlook) Der Verbindungstest ist erfolgreich, überall der externe Name Verbindungsstatus (STRG, rechte Maus auf Outlook-Systray) überall der externe Name. Autodiscover.xml überall der externe Name Alle externen Urls bereits mehrfach geprüft, auch CAS (Set-ClientAccessService ...), überall der externe Name Plugins deaktiviert 36 Stunden gewartet Betrifft alle User, alle Clients (W10 - 1809 / RDSH W2K12 R2) DNS, nslookup ist auch korrekt. Outlook-Profil löschen und neu anlegen hilft. Aber genau das will ich doch nicht, dazu konfigurieren wir doch Autodiscover. Für Tipps woran das liegen könnte, wäre ich dankbar. Viele Grüße

Ist Raid 1 wirklich schneller als 10? Zum Lesen können mehr Spindeln verwendet werden und das Write Penalty ist, wenn ich mich richtig erinnere, auch 2 wie auch bei Raid 1.

Ist mir vorhin irgendwie durchgerutscht: Quelle: Link In multidomain Active Directory forests in which Exchange is installed or has been prepared previously by using the /PrepareDomain option in SETUP, this action must be completed after the /PrepareAD command for this cumulative update has been completed and the changes are replicated to all domains. Setup will try to execute the /PrepareAD command during the first server installation. Installation will finish only if the user who initiated SETUP has the appropriate permissions.

Hallo, an vielen Stellen wird explizit darauf verwiesen, dass /PrepareAD ausgeführt werden soll. Das ist beim Exchange aber nichts neues. Bisher war es doch immer so, dass das Setup das komplett automatisch gemacht hat. Der Account muss natürlich über die entsprechenden Rechte verfügen. Hat sich da was geändert? Die Doku (bereits etwas älter) beschreibt es noch immer so. Es wird dieses Mal so auffällig darauf verwiesen. Bisher war es ja auch so, dass das Setup einen Fehler gemeldet hat, wenn z. B. ein zweiter DC gerade nicht online (Testumgebung aus Backup) war. Grüße

Ehrlich gesagt bin ich mir nicht sicher ob mir klar ist was du willst. Deine Fragestellung ist nicht eindeutig. Du willst eine Prozedur erstellen. Diese Prozedur soll Übergabeparameter haben. Du willst für mehrere Aufgaben nur eine Prozedur haben. Das willst du erreichen indem du die Parameter wahlweise mit null oder einem Wert belegst. Du machst ein "null" wenn der Parameter nicht berücksichtigt werden soll. Eine Variante habe ich dir oben gezeigt. Mit einem between geht das auch. select * from Tabelle where Betrag between coalesce(@Von, 0) and coalesce(@Bis, 9999999999) Einer Variable kannst du z. B. wie folgt einen Wert zuweisen. declare @Variable numeric(15,2); set @Variable = 50; Wenn du in der Parameterliste einer Prozedur einen Standardwert angeben willst, das geht auch: create procedure sp_MachHaltWas @nOption1 int, @nOption2 int = 5 --Wenn du diese Prozedur mit dem Standardparameter aufrufen willst, macht man das z.B. so exec sp_MachHaltWas 5, default

Hallo, du könntest das so machen: declare @sParam varchar(10); -- Beispiel, das ist natürlich dein Übergabeparameter select Feld from Tabelle where FeldBedingung = @sParam or @sParam is null Wenn du Tabellen mit sehr vielen Datensätzen hast, kannst du dir merken, dass ein "or" möglichst zu vermeiden ist. Mit viel meine ich jetzt aber nicht ein paar 1.000 sondern eher ein paar Nullen mehr. "Null" ist natürlich etwas anderes als 0.

Guten Morgen, hat jemand genauere Informationen zur Kompatibilität von Gastsystemen in Hyper-V (Server 2012 R2). Natürlich kenne ich die offiziellen Dokumente. https://docs.microsoft.com/de-de/virtualization/hyper-v-on-windows/about/supported-guest-os https://docs.microsoft.com/de-de/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn792027(v=ws.11) Windows Server 2019 ist somit nicht supported. Windows 10 hingegen wird pauschal genannt. Server 2019 habe ich schon mal spaßhalber als Gast auf einem 2012 R2 getestet. Die VM mit einem SQL-Server lieferte extrem schlechte Abfrageergebnisse. Gleiche VM auf einem W10 1809 Host lief schnell. Werden nur bestimmte W10 Versionen als Gast auf einem Server 2012 R2 supported oder alle? Der Kernel soll ja gleich sein, deswegen dürften auch nicht alle W10 Versionen als Gast auf einem Server 2012 R2 supported werden. Die Doku ist da widersprüchlich. Danke und Grüße

Danke. Nicht an den SMTP binden als Alternative, das ist dann wohl ein Fall für die Sache mit dem Wald und den Bäumen.

Guten Tag, bitte beantwortet mir folgende Frage. Mein Exchange arbeitet derzeit noch mit dem bei der Installation selbst ausgestellten Zertifikat. Mit iOS 12 können aber selbst signierte Zertifikate nicht mehr akzeptiert werden. Die ganzen "Tricks" wie Neustart, Zugangsdaten erst falsch dann richtig eingeben usw. funktionierten nur bis iOS 11. Da es aber sowieso nicht schön ist selbst signierte Zertifikate öffentlich zu verwenden bekommt der Exchange jetzt ein eigenes Zertifikat. Die Konfiguration an sich ist gut dokumentiert und sollte keine Probleme bereiten. Hier https://docs.microsoft.com/en-us/previous-versions/exchange-server/exchange-150/mt595782(v=exchg.150) heißt es: "We recommend that your certificate's common name match the primary SMTP domain for your organization." Was will mir das sagen? Hier: https://www.frankysweb.de/exchange-2016-smtp-connector-und-wildcard-san-zertifikate/ werden die Probleme beschrieben die auftreten wenn das nicht so ist. Meine Domäne heißt intern leider anders als extern. Der Exchange hört intern auf den Namen exchange.firma.local extern auf exchange.firma.de. Den DNS konfiguriere ich intern so, dass der externe Name auf die interne IP aufgelöst wird. Mein Zertifikat wird ein SAN-Zertifikat mit CN=exchange.firma.de und als weiteres Attribut autodiscover.firma.de. Es sollte doch völlig egal sein wie der interne Name des Exchange ist, so lange die Verbindung über den externen Namen auch intern verwendet wird. Der Exchange kann blabla.xyz.local heißen wenn das Zertifikat auf exchange.firma.de lautet und die Verbindung auch so aufgebaut wird. Konkret denke ich darüber nach ob es mir Probleme bereitet, wenn der Exchange exchange.firma.local heißt das Zertifikat auf exchange.firma.de lautet und meine Standard SMPT Domain nicht die *.de sondern die *.local ist. Wird das Probleme machen? Danke

Das ist nicht richtig. "Veeam Agent for Windows" unterstützt die konsistente Sicherung von SQL-Instanzen, egal in welcher Version. Eigentlich sogar zwangsläufig, weil Schattenkopien genutzt werden. Was in der "Free" Version nicht unterstützt wird, ist das was bei Veeam "Application-Aware-Processing" genannt wird. D. h. du hast in der "Free" Version keinen Einfluss auf das "Wie" der Sicherung. Voraussetzung dafür ist ein installierter und funktionierender "SQL Server VSS Writer", der ist aber bei einer Standardinstallation sowieso vorhanden. Das aber trotzdem prüfen! "Veeam Agent for Windows FREE" macht eine Kopiesicherung, d. h. eine parallel laufende SQL-Sicherung mit Bordmittel wird nicht beeinflusst. Du kannst das alles anhand der Events und der Einträge in [msdb..backupset] nachvollziehen. Das hier auch genannte/verlinkte "Veeam Backup Free Edition" ist nicht geeignet, du schreibst nichts von Virtualisierung. Der größte Nachteil des "Veeam Agent for Windows" ist eine fehlende Prüfung ob das gemachte Backup auch korrekt gemacht wurde. Das soll aber in einer der nächsten Versionen eingebaut werden. Wenn du "Veeam Agent for Windows" nutzt, solltest du dir das Recovery anschauen: Funktioniert ein erstellter Wiederherstellungsstick? Recovery auf leere HDDs, die Partitionierung / Mapping muss da manuell gemacht werden. Du solltest dich mit dem SQL-Server in folgenden Punkten beschäftigen: Wiederherstellungsmodell, Backupvarianten. Dann kannst du schnell beurteilen ob das Backup mit "Veeam Agent for Windows" in dein Konzept passt. Ich sichere den SQL-Server immer mit Bordmittel, je nach Aufgabe des Servers noch zusätzlich mit Veeam (VAW, VBR). Schönen 1. Mai wünsche ich.

Guten Morgen, ich fasse nochmals kurz zusammen um was es hier ging. Ich meine man sollte Threads nicht einfach im Nichts enden lassen. Zu Anfangs ging es um die Verwaltung der lokalen Accounts: Empfehlung LAPS Die Diskussion ging dann über wie ein Wartungsaccount für Domänenmitglieder aussehen könnte: Empfehlung Domänenuser ohne lokale Adminrechte + lokaler Account mit dem PW aus LAPS. Weiter ging es dann mit der Frage ob ein Domänenuser mit lokalen Adminrechten und den genannten Einstellungen nicht genauso gut wäre: Keine Empfehlung bzw. unterschiedliche Meinungen. Meine Überlegungen dazu waren: Es ist so schlicht einfacher/bequemer und dem Domänenuser ohne lokale Adminrechte müsste ich das Recht geben die per LAPS vergebenen Passwörter aus dem AD auszulesen. Das kann dann aber auch Malware. Das schmeckt mir wiederum nicht. Hat der User nicht das Recht das PW zu ermitteln muss das ein anderer User, schreibe ich dann das PW auf einen Zettel um es bei der UAC-Abfrage einzugeben? Alle einzelnen Maßnahmen eines Sicherheitskonzeptes sind auf unterster Ebene immer irgendwie akademischer Natur. Wie lang muss das Passwort sein, macht das Scannen mit dem verbundenen Aufbrechen verschlüsselter Verbindungen Sinn, filtere ich Email-Anhänge, betreibe ich Geo-Blocking usw.. Ich habe hier im Forum einfach mal nach Malware gesucht. Erstaunt haben mich die teilweise unwidersprochenen Kommentare, dass bei Malware auf einem einzelnen Rechner das komplette Netzwerk neu installiert werden soll. Sollte eine durchdachte Rechtevergabe nicht genau das verhindern können? In diese Richtung gehen meine Überlegungen. Microsoft denkt auch darüber nach: https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/best-practices-for-securing-active-directory. Da habe ich auch die Empfehlungen entnommen. Ich schätze alle weiteren Kommentare, ansonsten können wir das auch beenden.