AFM_Adm

WorkDays WorkingHoursStartTime WorkingHoursEndTime WorkingHoursTimeZone -------- -------- --------------------- ------------------- -------------------- Weekdays 08:00:00 18:00:00 Pacific Standard Time Anscheinend passt auch die Zeitzone nicht. Aber egal was ich einstelle, in Outlook kann ich für das Raumpostfach immer nur 8.00 - 17.00 Uhr buchen, obwohl auch die Einstellung "Terminplanung nur während der Arbeitszeit zulassen" für das Raumpostfach deaktiviert ist.

Hallo zusammen, ich habe folgendes Problem mit Exchange 2016 onpremise. Ich möchte das ein Raumpostfach auch nach 17.00 Uhr (Working Hour) buchbar ist. Die Einstellung "Terminplanung nur während der Arbeitszeit zulassen" ist für das Raumpostfach deaktiviert, desweitern habe ich testweise die Working Hours für das Postfach geändert. Leider ist es in Outlook immer nur von 08.00 - 17.00 Uhr buchbar. Vielleicht kennt jemand von Euch das Problem oder hat einen Tipp.

Chkdsk /f hatte ich in einem Wartungsfenster bereits ausgeführt und dabei das Volume offline genommen.

Chkdsk sagt alles ok. ACL Änderungen mit Boardmitteln zu monitoren ist so eine Sache. Ich finde man kann dies sehr schlecht auswerten und darstellen. Oder hast du einen Tipp für ein gutes Tool?

Haben wir bisher auch noch nie erlebt, die Berechtigungen sind aber von 2012R2 nach Server 2016 mitgewandert und unter 2012R2 hatten wir auch nicht das beschriebene Problem. Leider tritt es auch nur sporadisch bei Berechtigungsänderungen auf, konnte es leider noch nicht reproduzieren. Die Berechtigungen sind vererbt, wir arbeiten da mit Anwenden auf "Nur dieser Ordner". Owner der entsprechenden Ordner ist die Administratoren-Gruppe. Symlinks nutzen wir nicht.

Hallo zusammen, wir nutzen einen Fileserver auf Basis von Windows Server 2016 Std. mit aktuellen Patches. Wir haben manchmal folgendes Problem, welches bei den Sicherheitsberechtigungen auftritt. Wenn wir Berechtigungen an Unterordern editieren, verliert teilweise ein Ordner mehrere Ebenen darüber Sicherheitsberechtigungen für einzelne Gruppen. Erst konnten wir das Problem nicht richtig nachvollziehen und haben gedacht wir hätten einfach für einen falschen Ordner Berechtigungen angepasst. Da es nun aber mehreren Kollegen des Öfteren passiert ist und definitiv die Sicherheitsberechtigungen für den korrekten Ordner bearbeitet haben, schließen wir das aus. Auftreten tut dies erst seitdem wir das Filesystem unter Windows Server 2016 laufen haben, vorher (Server 2012 R2, 2012, 2008R2, etc.) ist uns dieses Problem nicht untergekommen. Für Änderungen an den Sicherheitseinstellungen nutzen wir den Windows Dateiexplorer. Hat jemand von Euch ähnliches Problem oder hat Ideen wie wir dem auf den Grund gehen können?

https://www.av-test.org/de/antivirus/unternehmen-windows-client/

Habe ich mir schon gedacht, also ist Defender ohne SCCM keine wirkliche Alternative. Danke :)

Es geht primär um Windows 10 Clients mit Office Anwendungen und "normalen" Schutzbedarf. Also als Alternative zu der klassischen AV-Lösung ohne weitere Funktionen. Wert wird auf Reporting und Remote Verwaltung gelegt.

Wie schaut das mit dem Management aus, wenn man kein SCCM hat? Klar kann man mit PowerShell einzelne Clients abfragen, aber wie bekommt man ein gescheites Reporting mit Benachrichtigung hin, welche Möglichkeiten gibt es da?

Hallo zusammen, hoffe mal das hier ein paar den System Center Data Protection Manager (DPM) einsetzen. Ist euch beim DPM schon mal untergekommen, dass wenn man ein Wiederherstellungsziel für die Beibehaltungsdauer (schreckliches Wort ) löscht, dass DPM die Beibehaltungsdauer für die bestehenden Bänder anpasst? Konkret haben wir bisher Wochen (Wiederherstellungsziel 1), Monats (Wiederherstellungsziel 2) – und Jahresbänder (Wiederherstellungsziel 3) erstellt. Diese haben eine Beibehaltungsdauer von 4 Wochen, 12 Monate und 10 Jahre. Nun wollten wir keine Wochensicherungen auf Band mehr erstellen, da wir diese auf Disk machen. Wenn man nun die Wochensicherung (Wiederherstellungsziel 1) löscht, sind auf einmal die alten Wochenbänder 12 Monate und die Monatsbänder 10 Jahre gültig, bis diese ablaufen. Also irgendwas verrückt DPM da...

Wie lautet denn die Fehlermeldung die du per RDP erhälst?

So, kurzes Update: Ich hatte ein Ticket bei MS aufgemacht. Nach 4 Wochen Bearbeitung wollen sie das Ticket zu machen, da die Funktionalität des Betriebssystems nicht beeinflusst wird. Ich habe in der Zwischenzeit weitere Tests gemacht und konnte das Verhalten auch auf anderen Servern, auf denen die ISCSI-Initiator genutzt wird reproduzieren. Sobald ich einmal irgendeine IP bei den iSNS Server Einstellungen eingetragen habe, versucht das System die IP in Japan zu erreichen. MS kennt die IP Adresse nicht und hat es auf andere Software geschoben. Als ich dies durch Tests wiederlegen konnte ist Ende und wollen das Ticket schließen.

Die beiden Server sind eigentlich sauber ausgesetzt und haben bis auf die Dell Tools keine 3rd Party Software drauf. Virenscanner hat auch nichts gefunden, schließe ich von daher erstmal aus.

ServerView kenne ich nicht, ist ein Dell Server. Die Dell Services hatte ich aber auch schon mal alle auf dem Server deaktiviert, der Eintrag im Ereignislog kam aber trotzdem noch alle 30min. Habe mit dem Process Monitor herausgefunden, dass folgender Process versucht die entsprechende Adresse zu erreichen: C:\Windows\system32\svchost.exe -k netsvcs Bringt mich leider aber auch nicht viel weiter...

Das habe ich auch schon versucht und leider nichts zu der Fehlermeldung gefunden...

Achso du meintest unseren Server, nein den kann man nicht von extern (WAN) erreichen. Ich meinte eben den Server der hinter der öffentlichen IP steckt, der anscheinend versucht wird zu kontaktieren.

Nein, zumindest nicht per http, https und iSNS (Port 3205).

Nein, wir verwenden intern nur private IP's und kennen diese IP nicht.

Moin zusammen, wir haben auf 2x Windows Server 2016 im halben Std. Rhythmus ein Event 112, Quelle MSiSCSI: Fehler bei der iSCSI-Ermittlung über Internet Storage Name Server (iSNS) bei iSNS-Server "öffentliche IP in Japan". Fehlercode 0x0000274d. In den Einstellungen im iSCSI-Initiator ist kein iSNS-Server eingetragen. Hat jemand vielleicht ein ähnliches Phänomen unter WS2016 beobachtet? Wie komme ich der Sache auf die Schliche, würde gerne wissen wieso die beiden Server zu dieser merkwürdigen öffentlichen IP connecten möchten.

Habe das Problem gefunden, lag anscheinend an den Schattenkopien. Wenn diese vorher für die Volumes gelöscht werden, geht das ändern von den Laufwerksbuchstaben innerhalb einiger Sekunden. Danke und guten Rutsch :)

Unter "Datenträgeraktivität" wird der entsprechende Prozess leider nicht angezeigt. Nur unter "Prozesse mit Datenträgeraktivität" wird System mit der hohe Leserate angezeigt und unter "Speicher" sehe ich das der Wert für die Datenträgerwarteschlange nach oben geht.

Sind einige TB's. Ist leider keine Alternative. Ich frage mich auch was der da so auf dem Datenträger liest beim ändern des Laufwerkbuchstabens? Was steckt dahinter was macht er im Hintergrund?

Eventlog meldet leider nichts dazu, keine Fehler oder Probleme und auch keine Info Einträge.

Moin zusammen, ich habe eine VM mit Windows Server 2012 (aktuelle Patches). Ich möchte die angehängten VHDX an eine andere VM umhängen und daher innerhalb der VM die Laufwerksbuchstaben ändern, da diese auf der anderen VM andere Zuordnungen (Buchstaben) erhalten hat. Ich habe es bereits über die GUI (Datenträgerverwaltung) und mit diskpart probiert. Entweder dauert es Std. oder die GUI hängt sich komplett weg. Virenscanner habe ich schon ausgeschlossen. Was mir noch aufgefallen ist: Es gibt eine relativ hohe Leserate auf dem Datenträger für den der Laufwerksbuchstabe geändert werden soll. Hat sonst vielleicht jemand eine Idee wie ich die Laufwerksbuchstaben ändern kann oder woran dies liegen könnte?