SBK

Hallo Leute, Ich bin im Moment an einer Migration eines SBS2011 nach Exchange 2016. Die Installation des Exchange2016 hat einwandfrei geklappt. Im Moment habe ich aber ein relatives banales Problem. Wenn ich auf dem Exchangeserver die virtuellen Verzeichnisse (OWA und ECP) anpasse und auf die offizielle Domain owa.domain.ch setze, lande ich nach dem Login des Exchange Admin Center, nicht mehr in der Konfigurationskonsole aber im OWA des Exchange2010. Die OWA-Adresse (intern und extern) verweist natürlich noch auf den Exchange2010. Ich möchte aber erst testhalber ein Postfach auf den Exchange2016 verschieben und austesten bevor ich alles auf den neuen Exchange2016 umstelle. Wie kann ich die virtuellen Verzeichnisse auf Exchange2016 auf die offiziellen Adresse umstellen und dabei weiterhin auf das EAC zugreifen? Gruss SBK

Hallo Leute, Ich bin heute über den Active Directory Papierkorb gestolpert (SBS2011 mit Forrest Functiontal Level Server 2008 R2) und wollte diesen für unsere Domäne aktivieren. Habe zwar die letzten 20 Jahre noch nie eine OU oder AD-Objekt fälschlicherweise gelöscht, aber man wird ja älter... Nun ich habe die Anleitung unter https://lanbugs.de/howtos/windows-tipps-tricks/windows-2008-r2-server-active-directory-papierkorb-aktivieren-und-verwenden/ befolgt. Wenn ich den Befehl Enable-ADOptionalFeature –Identity 'CN=Recycle Bin Feature, CN=Optional Features,CN=Directory Service,CN=Windows NT, CN=Services,CN=Configuration, DC=sbknt2003,DC=local' –Scope ForestOrConfigurationSet –Target 'sbknt2003.local' eingebe erhalte ich aber jeweils die Rückmeldung: Enable-AdOptionalFeature : Die Zugriffsrechte reichen für diesen Vorgang nicht aus. Ich bin aber Admin, Schema-Admin und Enterprise-Admin. Was will dieser denn noch für Rechte? Gruss SBK

Ich hatte dasselbe Problem bei einem neuen Windows Server 2016, ich bin die Tipps von Sunny alle durchgegangen alles erfolglos. Was schlussendlich das Problem löste, war der GPO-Eintrag: Keine Verbindung mit Windows Update-Internetadressen herstellen von aktiviert auf nicht konfiguriert zu stellen. Dies nur falls jemand anderes über das Problem stolpert. Gruss SBK

Nun ja es besteht anscheinend Hoffnung das Microsoft einen Hybrid Connector entwickelt und onPremise Server nicht mehr für das AD Connect verlangt: https://techcommunity.microsoft.com/t5/Azure-Active-Directory/Tips-to-use-Azure-AD-Connect-with-online-Exchange-management/td-p/122146 Falls jemand heiratet erfasse ich vorübergehend die zusätzliche Mail-Adresse via Attribut proxyAdresses oder hoffe das es bis dann einen Hybrid Connector gibt...

Jep ASR, das bin ich mir am überlegen. Das Problem ist das bei einer Cutover Migration das Passwort mit Office 365 nicht synchronisiert wird und ein Single Sign on ist eigentlich erwünscht. Eine Alternative ware ein Standard Server 2016, Essentials Rolle und die Integration mit Office 365, dort sollen Passwörter synchronisiert werden. Aber auch da findet man mehrere Hinweise dass AD Connect besser ist als die Integration bei Essentials. Darum wollte ich AD Connect einsetzen, aber das wird in Zusammenhang mit ADSI Edit oder erweiterte Attribute nicht supportet resp. benötigt einen Exchange Hybridserver. Also drehe ich mich im Kreis... Nachtrag an mwiederkehr: Ich werde wohl die Variante AD Connect und Attributeditor für weniger als 5 User wählen. Dennoch merkwürdig das hier Microsoft den Ansatz nicht fertiggedacht hat und die Lösung als nicht supportet einstuft. Da waren die Lösungsansätze mit SBS definitiv besser...

Ja genau und Du finanzierst mir diese gleich mit... Beachte das wir hier von kleinen Firmen mit bis zu 5 User reden, da ist das Budget sehr klein....

Danek Mathi, das mangen dürfte einfacher sein. Den Exchangeserver muss ich dann aber auch wieder updaten, belegt Speicherplatz und was mir noch fast wichtiger ist, er belegt ja auch einen Hyper-V-Lizenzkey. Normalerweise kann ich ja auf einem Windows Server 2016 Standard 2 Hyper-VM's laufen lassen. Das heisst wenn ich einen Exchange 2016 installiere, bleibt nur noch eine Hyper-VM übrig. Oder liege ich da falsch? Der Hybrid-Key gilt ja nur für den Exchange 2016 Server....

Hallo Leute, Ich habe da mehrere SBS2011-Server, welche ich in den nächsten Monaten durch Office 365 ablösen möchte. Hierbei habe ich etliche Anleitungen durchgelesen, wie z.B. https://www.itpromentor.com/migrate-2010-to-365/ Was mir noch nicht ganz einleuchtet ist ob ich onPremise noch immer einen Exchangeserver braucht, wenn ich die Passwörter synchronisieren möchte. Gemäss verschiedenen Anleitungen ist ein Hybridserver onPremise zwingend. Andere Webseiten https://www.msxfaq.de/cloud/identity/dirsyncexchange.htm sagen das man die Attribute via ADSI-Edit oder erweiterte Attribute (Bsp. proxyAdresses) editieren kann, dies aber nicht offiziell supportet wird. Bei 50 oder mehr Postfächer ist ein Exchange2016 als Hybridserver auch kein Problem aber bei ca. 5 Postfächer ist das entschieden übertrieben (auch wenn nur eine VM). Hat jemand von Euch die Migration auf Office365 durchgeführt und KEIN OnPremise Exchangeserver im Einsatz resp. synchronisiert die Passwörter wie ADConnect? Gruss SBK

Nein die Option ist bei allen Clients deaktiviert und ich setze den Standarddrucker jeweils übers Anmeldeskript (abhängig vom Stockwerk) mit folgendem Befehl: cscript \\server\sysvol\domain.local\scripts\prnmngr.vbs -ac -p "\\server\2etage" PS: Vielleicht noch ein wertvoller Hinweis, ich verwende jeweils die PCL6-Druckertreiber und nicht die PS-Druckertreiber...

Ich pushe diesen Beitrag mal wieder hoch, da das Problem nach wie vor ungelöst ist. Ich habe auf 25 Clients sporadisch mal einen Benutzer oder 5 Benutzer pro Woche, welche nicht mehr Drucken können und die Meldung erscheint: kein Drucker installiert. Drucker sind aber alle korrekt installiert. Dabei spielt es auch keine Rolle ob ich via Word, Outlook oder Adobe Reader Drucker. Auch der Neustart des Druckspoolersdienstes bringt keine Besserung. Nur wenn man den PC komplett neu startet, ist das Problem behoben und der Spuk vorbei. Ich konnte aber nicht herausfinden was es auslöst. Da können die Leute 8 Stunden arbeiten und dann passiert es oder gleich 5 Minuten nach Arbeitsbeginn. Auch habe ich andere Treiber ausprobiert (Im Moment verwende ich die neusten HP Universal Driver Version 6.6.0). Auch passiert das Problem ungeachtet des Herstellers (wir haben zwar nur HP Drucker, aber auch Canon Fotokopierer) . Da das Problem nur sporadisch passiert, ist es schwierig das Problem auf einem neu installierten Client nachzustellen. Hat jemand eine Idee voran das über Server freigegebene Drucker liegen könnte? Gruss SBK PS: Schnellstart und Computer kann das Gerät ausschalten, um Energie zu sparen sind beide deaktiviert.

Danke Nobbyaushb, werde am Juni Patchday die VM's definitiv runterfahren. Die Updates werden sowieso am Abend spät installiert, da spielt es auch keine Rolle wenn die VM's 30 Minuten nicht laufen. Gruss SBK

Ja, schau weiter oben... Anzahl der Akkus/Kondensatoren 1 Akku-/Kondensatorstatus OK

Hi Djmaker, Der Schreibcache für logische Laufwerk ist bei allen HP-Servern defaultmässig deaktiviert. Ich habe mal versucht diesen zu aktivieren (Server hängt ja auch an einer USV der 15 Minuten überbrückt), aber es erscheint die Meldung dass die Einstellung nicht geändert werden darf oder das Feature vom Gerät nicht unterstützt wird. Ev. liegt es am RAID-Controller, der die Einstellung übersteuert. Gruss SBK

Ok, perfekt so kann ich die Einstellung beruhigt deaktiviert lassen. Die Cache ratio ist anscheinend bei unterschiedlichen Firmwareversion anders eingestellt siehe auch https://serverfault.com/questions/376524/strategy-to-optimize-raid-cache Ich werden diese beim perfmon mal mit 75/25 read/write überwachen und ggf. auf 50/50 oder zurück auf 10/90 zurückstellen. Mal schauen ob das eine Veränderung bringt.

Interessant, die Einstellung wurden vom HP Smartarray Assistent selbständig vorgenommen, aber ich habe diese gleich geändert. Danke für den Hinweis. Dabei bin ich noch die Smart Array Einstellungen durchgegangen. Alle Einstellungen erscheinen mir plausibel, bis auf eine. Dort steht Schreib-Cache-Status für physische Laufwerk, diese Einstellung ist deaktiviert. Müsste diese nicht aktiviert sein?

Ja, eine Cache Batterie ist installiert und aktiviert. HP Smart Storage Administrator meldet: Cache-Status OK Größe des Controller-Cache-Moduls 2048 MiB Im Cache verfügbarer Speicher insgesamt 1816 MiB Anzahl der Akkus/Kondensatoren 1 Akku-/Kondensatorstatus OK Caching-Einstellungen Cache-Verhältnis 10% Lesen / 90% Schreiben Schreib-Cache aktivieren, wenn Akku/Kondensator nicht vorhanden oder nicht vollständig aufgeladen Deaktiviert Schwellenwert für Schreib-Cache-Umgehung unterstützt Nein Gruss SBK

@zahni: Es handelt sich hierbei um einen ML350 G9 Server, mit einem P440ar Smart Array Controller, 3 SAS-Platten (RAID5) 10k an je 600 GB., also effektiv 1.2 TB verfügbarer Speicher. Die zwei VM's sind als WSUS-Server und Remote Desktop Server installiert resp. konfiguriert. Auf dem Host läuft nebst der Hyper-V-Rolle und den HP Proliant Tools keine weitere Software. Gruss SBK

Hallo Marple, Werde die Datenträgerauslastung während den Updates gerne beobachten. Im normalen Betrieb mit 2 VM's pendelt die Datenträgerauslastung zwischen 1-40%. Es gibt aber festzuhalten das ich auch nur ein RAID5 als gemeinsame Festplatte habe (Proliant Server). Es könnte durchaus sein das der Flaschenhals die Festplatte ist, aber gleich 2 1/2 Stunden anstelle von 15 Minuten, erscheint mir relativ viel. Wie gesagt, ich poste hier am nächsten Patchday mal das verhalten und beobachte die Datenträgerauslastung während den Updates von VM's und Host.... Danke und Gruss SBK

Danke Zahni und NilsK, da habe ich schon wieder etwas dazugelernt. Da hätte ich ja noch mehr als genügend Reserven mit den virtuellen CPU's... OK, ich werde im Juni Patchday noch schauen ob man mit dem beenden der VM's etwas die Updates beschleunigen kann und sonst lebe ich einfach damit. Bei den VM's und beim normalen Arbeiten, bemerkt man sonst keine Beeinträchtigungen oder sonstige Verzögerungen. Thanks und Greetings SBK

Jep, da hast Du Recht zahni. Könnte das der Grund sein, dass die Updates auf dem Hyper-V-Server so langsam installiert werden? Denn damit habe ich 8 virtuelle Kerne von 8 verfügbaren Kerne den beiden VM's zugewiesen...

Hallo NilsK, Der Hyper-V Server hat 48 GB RAM, davon sind je 16 GB an zwei Maschine zugewiesen und somit hat der physische Server ebenfalls noch die restlichen 16 GB RAM. Die CPU ist eine Intel Xeon E5-2620 v4 @ 2.1Ghz. Je 4 virtuelle Prozessorkerne habe ich den virtuellen Maschine zugewiesen. Die CPU hat ja insgesamt 16 Kerne. Der Leistungsmonitor des Servers zeigt nichts aussergewöhnliches, CPU dümpelt bei 3% Belastungen und Arbeitsspeicher ist zu 59% belegt (die VM's laufen ja). Ich werde beim Juni-Patchday die VM's vor dem Windowsupdate herunterfahren und das zeitverhalten beobachten. Gruss SBK

Danke NilsK, da es sich hierbei um eine sehr kleine virtuelle Infrastruktur handelt (im Moment nur ein Hyper-V Server). Kann ich die VM's nicht per Live Migration verschieben. Aber ich werde beim nächsten Patchday, mal die virtuellen VM's am Abend spät herunterfahren und das Zeitverhalten beobachten. Es ist einfach nur auffällig das der Hyper-V Server fast 10 Mal länger braucht als alle anderen physischen und virtuellen Maschinen und das obwohl er eigentlich neuer als alle anderen ist und dadurch auch mehr CPU- und RAM hat. Gruss SBK

Hallo Leute, Ich habe eine Frage wie man optimal die Windows Update bei einem Hyper-V-Server (Server 2016) installiert. Wir haben WSUS im Einsatz und die Verteilung funktioniert jeweils auf allen Server einwandfrei, bis auf den Hyper-V Server. Gestern habe ich unter anderem das Mai 2018 Qualitätsupdates (KB4103723) freigegeben. Auf allen Server und virtuellen Hosts wurde das Update innerhalb 10 oder 15 Minuten installiert. Beim Hyper-V-Server (mit zwei virtuellen Hosts) hat das ganze 2,5 Stunden gedauert. Das Phänomen ist nicht neu auch beim März und April Update hat das jeweils mehrere Stunden gedauert. Ich frage mich nun ob ich da etwas falsch mache. Muss man die virtuellen Hosts, beim Update vom Hyper-V Server, erst herunterfahren? Im Eventprotokoll und auch bei anderen Updates (Bsp. HP Proliant Support Pack) ist das Verhalten absolut im grünen Bereich. Danke für eure Antworten. Gruss SBK

In der Tat waren die Domainuser als lokale Admins auf dem RDS-Server definiert. So nun greift auch die GPO, unabhängig ob mit OU oder WMI-Filter. Danke und Gruss

Danke für die Tipps, werde mal gleich eine OU anlegen und das ganze ausprobieren.