Mack

Die müsste ich dann ja auch in der Übersicht der ausgestellten Zertifikate sehen. Und dort sind keine.

Hallo zusammen, ich habe hier einen Small Business Server 2011 welcher auf neue Hardware in eine Hyper V Umgebung (1 DC VM und 1 Exchange VM) migriert wird. Es ist soweit auch alles umgezogen. - DNS, DHCP, Shares, Printer, kompletter Exchange (alter 2010er bereits deinstalliert) und die FSMO Rollen. Sharepoint wurde/wird nicht genutzt Soweit ist also quasi alles drüben und läuft. Für den neuen Exchange wurde ein Geotrust SAN installiert, mit Split DNS für intern und extern und läuft soweit. Nun steht das demoten des alten DCs an und die Frage vorab im Raum, brauche ich die AD integrierte Zertifikationsstelle noch? Dort sind "nur" Zertifikate für die "sites", die CA an sich, sowie den neuen und alten DC enthalten. Kann ich die CA dann einfach deinstallieren? Wie schaut es dann mit dem DC Zertifikat des neuen DC und dem Vertrauen der Clients im Netzwerk aus? Wenn ich eine Domäne neu aufbaue und die Zert-Rolle anfänglich nicht installiere, vertrauen die Clients dem DC ja auch ohne einer CA. Oder ändert sich da etwas sobald einmal eine AD CA im Spiel ist? verwirrte Grüße Dirk

Moin Nils, Danke, den Link kannte ich schon. Wäre eben noch interessant, wie diese Belegungsdifferenz zu erklären ist . Ich finde im Netz immer nur die umgekehrte Situation, dass die vhdx größer sind als ihr Inhalt. Aber das erklärt sich ja dadurch, dass freigebener Platz nicht zu einem Shrink der vhdx führt. Mein Problem ist ja, dass die vhdx auf der UPD Freigabe 400 MB anzeigt und gemountet inside 1 GB Belegung aufweist.

Wir haben eine Windows 2012 R2 Serverfarm mit 2 RDS Host und einem Broker. Die Userprofile werden per UPD auf einem Fileserver bereitgestellt. Genutzte Anwendungen auf der RDS Farm sind Office 2016 (primär, Word/Excel/Outlook im Onlinemode mit Exchange) Die Maximalgröße wurde auf 1 GB gesetzt, was sich nun wohl als viel zu niedrig herausstellt. Wir hatten hier Erfahrungswerte aus der alten 2008 R2 Farm genommen, wo allerdings mit Roaming Profiles für die Terminalserverprofile gearbeitet wurde. Und da waren die Profilgrößen teils weit unter 1 GB. Nun melden die ersten User Problem beim speichern etc, weil angeblich kein Speicherplatz vorhanden wäre. Schaue ich mir die vhdx Datei des Users auf der UPD Freigabe an, belegt sie etwa 450 MB. Ich lasse also den User abmelden, um die VHDX zu mountenund sehe im Arbeitsplatz plötzlich fast 1 GB Belegung. Wenn ich nun mit TreeSize die Ordner ausfindig machen möchte, welche soviel belegen, kommt TreeSize ebenfalls nur auf 450 MB in der Summe. Fragen: Ideen, wo diese massive Differenz ("außerhalb" und "innerhalb" der VHDX) herkommt? empfohlene Größen für UPD? Bestehende VHDX kann ich wohl nicht vergrössern, sondern das Feature nur deaktivieren, neu aktivieren mit neuer Größenangabe, welche dann im Template für neue VHDX angewandt wird?! Die alten VHDX würden danach aber noch funktionieren, sodass ich Stück für Stück die vollaufenden UPD der User erneuern könnte? Update: Als Direktmaßnahme, habe ich jetzt mal ein Abmeldescript angelegt, dass die temp. Dateien im Profil des Users löscht. Den größten Anteil bei dem betroffenen User hatte der Terminal Server Client Cache mit 3 x 100 MB Datein. Jetzt wird es etwas strange. Um das Script nun zu testen, habe ich den Inhalt vom Cache in ein 2. Profil kopiert. Und plötzlich steigt auch in diesem Profil der belegte Bereich in der User Disk von bis dato 250 MB auf 980 MB, obwohl ich 3 x 100 MB und eine 0 kb große bcache24.bmc Datei kopiert habe. Ich schätze mal die Antwort zu den Differenzen liegt in der bcache24.bmc? Damit der Cache was cachen kann, muß er doch auf der Clientseite in der Zweigstelle sein. Was hilft der Cache auf dem Fileserver in der Zentrale, dem Client, der von Außerhalb per RDP zugreift. Auf der Clientseite in der Zweigstelle finde ich im lokalen Windows User Profil zwar auch die Cachedateien, aber die Frage bleibt für mich, warum die auch zentral abgelegt sind. Muss das quasi als Kopievorlage für den lokalen Client? Zumindest war nach dem Abmeldescript der belegte Speicher innerhalb der User Disk wieder bei guten 350 MB.

Ja. Von der Hardware her vollständig gleich, inkl. jeweils der lokalen USB, welche als Ziel dienen soll. Ursprünglich sollte dafür eigentlich eine NAS herhalten,aber nachdem einige Posts im Netz diesbezüglich Probleme mit dem Netzwerkstorage für möglich hielten, wurden die USB angeschafft.

Leider zeigt ein vssadmin list writers leider keine Probleme an und die Logs sind wenig aussagekräftig. Das Volume ist ja die systemreservierte Partition. Da liegt es nahe, mal ein Backup nur von C zu machen, ohne die systemreservierte. Dann behaupt Windows Backup allerdings, dass Laufwerk C nicht bereit wäre.

Update: Sorry. Ich habe die Fehlermeldung im Wortlaut ja komplett verschwitzt. Beim Aufruf des RDP Icons bekommen wir die Fehlermeldung: Es konnte keine Sperrprüfung für das Zertifikat durchgeführt werden. Im Übrigen habe ich in der CA in den Erweiterungen zu den CRL bei den Http Einstellungen die Haken gesetzt, "In Sperrlisten einbeziehen" und "In CDP-Erweiterung des ausgestellten Zertifikats einbeziehen.", ein neues Zertifikat erstellt und nun ein Zertifikat das auch eine Http Url enthält. Der Abruf der Sperrliste vom entsprechenden Client via Explorer funktioniert einwandfrei. Wenn man den Dialog, ob man trotzdem verbinden möchte, obwohl die Sperrprüfung nicht erfolgen konnte, mit Ja bestätigt, wird der Dialog wiederholt. Nach erneutem Bestätigen verbindet er sich per SSO ohne weiteres Murren. Beim nächsten Connect das gleiche Spiel.

Ok, sorry. War mir nicht bekannt. Bin ich noch nicht mit in Berührung gekommen. Via Explorer: Die Datei "\\?\Volume{b8aa7784-f8fc-11e6-80b3-806e6f6e6963}\" wurde nicht gefunden. Überprüfen Sie die Schreibweise, und wiederholen Sie den Vorgang. Aber Mountvol löst es weder als CSV noch als Laufwerk C, oder D (lokale USB) auf. Dort steht dann zur Vol ID nur "+++ KEINE BEREITSTELLUNGSPUNKTE ***"

Die Windows Server Sicherung ist an der Stelle leider recht ungenau und sagt nur: "Fehler beim Vorbereiten des Sicherungsabbildes eines der Volumes im Sicherungssatz. Detailierter Fehler: Das Gerät ist nicht bereit." In den Logdateien im WindowsServerBackup heißt es: "Fehler beim Sichern des Volumes "\\?\Volume{b8aa7784-f8fc-11e6-80b3-806e6f6e6963}\": Das Gerät ist nicht bereit." Ich habe leider nichts gefunden, wie ich die Volume ID zu einer konkreten Partition bzw. einem Laufwerk auflösen könnte. Der Fehlercode im Ereignisprotokoll lautet: "0x807800C5 - ("Fehler beim Vorbereiten des Sicherungsabbilds eines der Volumes im Sicherungssatz."). Microsoft vermutete einen Fehler in den VSS Writern. Dort sind aber alle Stati stabil und ohne Fehler

Ja, die Installation wurde von einem verifizierten DataCore Dienstleister gemacht. Gerade deswegen würde ich ja gerne auf die WSS setzen, um im Fehlerfall selbständiger sein zu können. Die Frage zur Fehlermeldung verstehe ich nicht. Oder meinst Du, ob ich mir sicher bin, dass es das CSV NICHT ist, welches den Fehler markiert? Wie gesagt, in der Auswahl zur Sicherung gibt es ja den Punkt das CSV explizit mit einzubinden in der Sicherung und das ist an der Stelle NICHT angewählt. Für ein BMR muss ich aber natürlich Laufwerk C: anwählen, und dort ist letztlich das CSV über C:\cluster Storage zu sehen. Ob es sich daran stört weiß ich nicht. Wir haben aber auch schon versucht nur einen Teil von C zu sichern. Auch dann bekomme ich den Fehler, dass das Vorbereiten eines der Volumes nicht möglich wäre. C: Das Gerät ist nicht bereit.

Eine Serverlandschaft wird Stück für Stück auf neue Hardware und neue Systeme (Windows Server 2012 R2) migriert. U.a. wird es auch eine RDS-Farm geben, welche durch ein Wildcard Zertifikat der AD eigenen Zertifikatsstelle die Verbindungen sichert. Die Anmeldung der User wird innerhalb der AD erfolgen. Damit die Anmeldung per Single Sign On ohne Hinweise beim Verbindungsaufbau abläuft, wurde - das WildCard Cert per GPO als vertrauenswürdige Stammzertifizierungsstelle und Herausgeber verteilt - auf den einzelnen RDHS installiert - der ermittelte Thumbprint an den RDS Dienst auf den einzelnen RDHS mit wmic /namespace:\\root\cimv2\TerminalServices PATH Win32_TSGeneralSetting Set SSLCertificateSHA1Hash="ThumbprintDesZertifikats" gebunden - die RDP Datei konfiguriert und danach via rdpsign signiert - Der Thumbprint via GPO in den trusted .rdp publishers bekannt gemacht Alles super. SSO verbindet den User ohne jegliche Meldung mit der Farm. Nun stand am Wochenende auch der Umzug der AD integrierten Zertifizierungsstelle an. To be honest, AD Zertifizierung ist nicht mein Steckenpferd und habe die Migration brav nach einer der diversen Migations HowTos gemacht. - Zert.stelle gesichert - Root Zert exportiert - Regkey der Konfiguration exportiert - Zert.stelle deinstalliert - Zert.stelle auf neuem Server installiert - Root Zert importiert - im Regkey den CAServerName auf den neuen Server geändert und importiert - Rücksicherung der CA - Neustart CA und alle Zertifikate wieder da Problem: SSO des RDP Icons bringt seitdem Fehlermeldungen Nach Ansicht des Zertifikates vermeintlich auch logisch, da CRL im Zertifikat ja noch auf die Sperrliste im alten Server verwies. Ok, flugs eine neues WildCard erstellt und ganzes Procedere oben bezüglich RDP SSO erneut durchgeführt. Leider meckert er noch immer, dass er die Sperrliste nicht überprüfen kann, obwohl der CRL Eintrag im Zert nun auf den neuen Server zeigt. Ein certutil -verify -urlfetch zeigt mir keine Fehler an, wenn ich das richtig interpretiere. Es gibt keine HTTP Url Einträge, sondern "nur" ldap, was meines Wissens innerhalb der Domäne ja ausreichen müsste. Gab es im Übrigen im alten Wildcard Zertifikat auch nicht und da lief es ja. Kann mir jemand auf die Sprünge helfen? Vielen Dank.

Ja, die Zahlung könnte ich natürlich zurückgehen lassen. Dann wäre ich auf jeden Fall auf einem Niveau angelangt, was wohl definitiv nicht mehr zielführend sein wird. Ich hätte gerne eine Lösung gehabt, das Geld, wäre es mir bei einem hartnäckigen Problem ja auch Wert gewesen. Wenn man Linux kann, ist es sicherlich eine Alternative. :-) Ja, die Platten sind hier auch offline und nicht initialisiert. Die Nodes haben je 2 Raid. Eines für das System und eines welches ausschließlich für das zukünftige DataCore vSAN vorgesehen ist, wo man dann das CSV ablegt. Das CSV als solches wird auch bei der WSS Sicherung explizit nicht angewählt. Indirekt (über den virtuellen Pfad c:\clusterstorage...) ist es natürlich mit aufgeführt, wenn ich eine BMR Sicherung definiere. Das war aber scheinbar für den DataCore Support kein Problem. DataCore sagt sonst halt: Neuinstallieren und neu konfigurieren. Die Konfiguration eines DataCore Nodes kann man über ein Backup restoren. Aber eben zu lasten von 1 Tag Arbeit mit Installation, Updates und den sonstigen Konfigurationen.

Pfft. Also soll ich ernsthaft die Kröte schlucken, dass ein Global Player wie Microsoft, Geld im voraus verlangt, quasi keine Leistung abliefert und sich geradezu verweigert, einem zu helfen? Das ist übelst traurig. So müsste ich mal Service verstehen. Aber Microsoft mit einem Quasimonopol scheint es sich wohl leisten zu können.

Jopp. DataCore spiegelt die internen Platten zwischen den Hosts zu einem virtuellen SAN, welches dann das CSV beherbergt.

Hallo Jan, den Manager hatte ich insgesamt 3x in CC. Bei der letzten Mail, war noch einmal der chronologische Abriss des gesamten Vorfalles aufgeführt und er sah sich wohl nicht genötigt, etwas zu unternehmen. Bei so einer Arbeitseinstellung bin ich dann ehrlich gesagt auch nicht mehr gewillt, mit den Leuten zu arbeiten, sondern hätte gerne ein neues Team. Aber es passiert ja nichts. Genau. Die clustered VMs werden mit Altaro Hyper V gesichert. Die Hosts wollen wir immer ganz gerne per WSS auf lokale USB HD sichern, damit wir ein schnelles BMR haben, für den Fall, dass einer mal aussteigt. Klar, kann man auch neu installieren, aber dann steht die Clusterkonfiguration bzw. vorab noch die DataCore- installation und Konfiguration an. Da wir diesen Teil seinerzeit eingekauft haben, wären wir mit einem BMR der WSS selber schnell handlungsfähig und müssten diese Schritte nicht erneut unternehmen (lassen). Die Fehlermeldungen sehen dann u.a. so aus: Fehler beim Sichern des Volumes "\\?\Volume{4df40386-0a5c-11e7-80b3-806e6f6e6963}\": Auf das bereitgestellte Sicherungsvolume konnte nicht zugegriffen werden. Wiederholen Sie den Vorgang.

Wir sind klein unser Herz ist rein. Wir sind nur registered. Da kriegst Du m.W. nichts geschenkt. :) Ich hoffe, das das nicht das einzige Statement bleibt. :( Und eigene Versuche haben wir natürlich vorab schon angestrebt.

Hallo Leute, ich weiß echt nicht mehr weiter. Wir haben Probleme bei einem neuem Hyper V Cluster mit Server 2012 R2 DataCenter die Hosts via der Windows Server Sicherung wegzusichern. Als CSV wird ein virtual SAN von DataCore eingesetzt. Mit der Sicherung der Hyper V Hosts bei anderen Installationen ohne DataCore HyperV Cluster, hatten wir mit WSS nie Probleme. So lag der Verdacht nahe, dass es etwas mit DataCore zu tun hat. DataCore sah dort aber keine Ursache, sodass wir uns an Microsoft gewandt haben und für 300,- EUR ein Case aufgemacht haben. Das war am 10.05. Am 11.05 hatten wir regen Kontakt und der Herr war sehr aktiv mit uns im Gespräch und willens uns zu helfen. Um es dann abzukürzen: - Es wurden später keine Zusagen über Rückmeldungen eingehalten. - Ich musste selber nachhaken, bekam keine Antwort, wandte mich an den Manager, der 2x eingreifen musste, bis sich der Techniker wieder meldete. - Und zwar mit der Aussage, dass er sich absprechen möchte, mit einem 3. und sich wieder meldet. Das war das letzte Mal, dass ich etwas gehört habe. Ich habe danach noch 2 x gemailt, u.a. in cc an den Manager. Nichts. Dann habe ich mittlerweile 3x mich telefonisch gemeldet bei der Support line, um Bewegung rein zu bringen. Beim 3. Anruf und weil ich beharrlich darauf bestand, das Ticket doch endlich mal zu eskalieren, wenn es denn schon keine Reklamationsabteilung bei Microsoft gibt, wurde dann dem angeblich nachgegeben und das Ticket eskaliert. Fragt sich nur, was Microsoft unter Eskalation versteht. Naja, das war am Montag, und ich habe nichts! Keine Lösung, Keine Email, Keinen Rückruf und im Online Ticket tut sich nichts! Ich bin echt fassungslos und habe keine Ahnung was ich machen soll. Kennt jemand so etwas und kann mir hier Vorgehensweise, oder Kanäle an die Hand geben, durch die sich endlich mal etwas bewegt? Man fragt sich echt wofür man Microsoft Partner ist und hier 300,- EUR auf die Theke legt.

Leider nein. Das liegt aber im Moment daran, dass keine funktionellen Probleme im täglichen Betrieb festgestellt werden und ich kein Servicezeitfenster für das CU5 bekomme. "Läuft doch, warum jetzt hier stören..." Also der Shot mit CU5 ist noch offen, wenn es das nicht bringt, werde ich den Call aufmachen. Ich hoffe, dass ich zeitnah die Möglichkeiten bekomme.

Jo, werde ich wohl müssen. Jetzt ist grad CU5 draußen. Dem geb ich vorher noch eine Chance. :-)

Moin Zusammen, alle SystemMailboxen hatte ich schon einmal neu gemacht. Ich habe jetzt noch einmal explizit nur das OAB neu gemacht und der Fehler taucht leider erneut auf. :-(

Hallo, ich pushe hier noch einmal, in der Hoffnung, dass doch noch jemand etwas einfällt. Das Thema besteht noch und ich habe leider weiterhin keine Idee, was hier schief läuft. Besten Dank schon einmal. Gruß Dirk

Öh, nein. Sorry. Natürlich CU4. Habe es oben korrigiert.

Der Server ist eine ein Exchange 2016 CU4 auf Windows Server 2012 R2, welcher von einem SBS 2011 migriert wurde. Soweit so gut. Leider bekomme ich 2 m.E. relevante Meldungen nicht weg und zwar: Quelle MSExchangeApplicationLogic mit Event ID 3028 & 3054. Mir ist aber auch nicht ganz klar, ob diese ursächlich zusammenhängen, denn auf einem anderen Ex2k16 in anderer Domäme habe ich Event 3028, aber ohne 3054. Primär macht mir daher auch eher die 3054 Sorgen. "Scenario: ProcessOrgExtensions. The organization mailbox for mydomain.tld could not be retrieved." Den Thread hier im Forum http://www.mcseboard.de/topic/207151-noch-zwei-fehlermeldungen-nach-der-migration/page-3 habe ich soweit auch durch, konnte aber m.E. keine Probleme beim OAB finden. Get-Mailbox -Arbitration liefert: Get-Mailbox -Auditlog: Get-Mailbox -Arbitration | where {$_.PersistedCapabilities -like “*oab*”} liefert: Get-OfflineAddressBook | fl name,versions,server,addresslists liefert: Ehrlich gesagt habe ich keine Idee, wo hier der Hase im Pfeffer ist. Kann mir jemand auf die Sprünge helfen? Vielen Dank. Gruß Dirk

Es wären weitere Lizenzen nötig, da die 2. ja bereits für den Exchange genutzt wird. Die Anschaffung kann ich leider nicht entscheiden, sondern lediglich anraten, was ich aber sicherlich nun noch einmal tun werde. Ich weiß in der Tat nicht, ob ich überhaupt in die Situation eines notwendigen Restores komme. Aber ich möchte meine (Warte)zeit nutzen, um auf die möglichen Lösungswege vorbereitet zu sein, weswegen ich hier um Unterstützung gebeten habe. Vielen Dank auf jeden Fall für eure Einschätzungen und Hinweise. Beste Grüsse

Hallo Zusammen, Nils, danke für die Links. Daraus fasse ich zusammen, dass ich das gemeinte Feature VM Generation ID, besser nicht beanspruche, da der Vorteil fragwürdig bzw. sehr explizit ist und keinen generelles "Fire and Forget" bietet. Und die Stichworte zum Thema AD Restore heißen dann wohl (non) authoritative Restore. Dass es generell Recht einfach und möglicherweise auch Best Practise ist, einen ausgefallenen DC durch einen neuen mit automatischer AD Replikation im Anschluß zu ersetzen, mag ich auch gerne nachvollziehen. Bei dem genannte Server werden aber allerdings einige weitere Funktionen auf dem Server aus Kostengründen laufen. AD, File, DNS, DHCP, PrintServer, GData Management Server, Onlinebanking, sowie eine datenbankbasierende Brachenanwendung. Alles im allem also eine Menge Funktionen, welche ebenfalls neu eingerichtet werden müssten und Datenbestände migriert werden wollen. Deswegen würde ich, wenn möglich, eben doch ein VM Restore in Betracht ziehen wollen, wenn es denn klappt. Dazu müsste also die Altaro Software die VM in einer Weise zurücksichern, dass das AD dabei im (non) authoritative Restore Modus läuft, um die AD Replikation sauber fortzuführen? Sollte die Altaro das nicht können, wäre dann eine denkbare Variante innerhalb der VM den System State mit Windows Server Sicherung zusätzlich wegzusichern? Beim VM Restore könnte man dann den DC ohne Netzwerkverbindung wiederherstellen, mittels der WSS den System State ebenfalls zurücksichernund dann online gehen? Das ist natürlich nur theoretischer Natur für die Zukunft, da ich aktuell keine AD Sicherung per WSS habe. Im Übrigen ist es zur Zeit noch unklar, ob der abgestürzte Server ggf. von den Platten auch ohne Restore noch bootet. Soweit komme ich leider im Moment gar nicht. Dann hätten wir doch gar kein Problem, gesetzt den Fall, dass das System das harte Abwürgen überstanden hat, oder? Richtig Dukel. Der Exchange wird bzw. ist auf einer 2. VM installiert und das aktuelle System ist ein Exchange 2010 SP3 mit letztem CU (15?). Also der Stand, ab dem eine Migration zu 2016 CU5 meines Wissens nach möglich ist.