MHeiss2003

Hallo zusammen, ich habe eine Exchange Umgebung mit einem CAS und einem Mailboxserver. Beide Server haben den aktuellen Patch Stand Exchange 2013 (Version 15.0 Build 1178.4) und Windows 2012 R2. Auf dem CAS Server kann ich problemlos auf den Administrative Center zugreifen. Auf dem Mailboxserver erhalte ich die Fehlermeldung HTTP-Fehler 404.0 - Not Found die gesuchte Ressource wurde entfernt oder umbenannt, oder sie steht vorübergehend nicht zur Verfügung. Angeforderte URL https://localhost:443/ecp/?ExchClientVer=15. Nach meinem Verständnis liegt auf dem Mailboxserver nur das Backend. Auf dem IIS ist in der Default Web Site nur der Ordner aspnet_client und die Seite PowerShell enthalten. Von ECP oder dergleichen nichts zu sehen. Ist der Zugriff auf den Administrative Center vom Mailboxserver aus generell nicht möglich? Danke für Eure Antworten. Mario

Hallöchen zusammen, kurz vor Weihnachten, habe ich ein merkwürdiges Phänomen. Alle Win7 Clients sind mit Office 2013 Pro Plus bestückt inkl. aller Updates, der Exchange Server 2013 Enterprise hat das aktuelle Update CU7, es ist alles aktuell. Nun erscheinen die öffentlichen Ordner in keinem Outlook, in OWA sehe ich diese sofort. Außerdem habe ich herausgefunden, dass wenn ich, was ich eigentlich nur zu Testzwecken nach der Migration durchgeführt hatte, ein öffentliches Ordnerpostfach als "Standardpostfach" einem Exchange Konto zuweise, die Darstellung schon nach wenigen Sekunden bzw. einem Schließen und erneuten Öffnen von Outlook korrekt erfolgt. Ich verwende den Befehl Set-Mailbox -Identity POSTFACH -DefaultPublicFolderMailbox "NAME PF Mailbox". Habt Ihr eine Idee, wie ich die Ordner für meine 55 Mailboxen sichtbar machen kann? Danke und Grüße Mario

Danke Dir Doso. Habe folgende Registry Werte überprüft: 1. HLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Printers\ 2. HCU\Software\Microsoft\Windows NT\CurrentVersion\Devices\ 3. HCU\Software\Microsoft\Windows NT\CurrentVersion\PrinterPorts\ 4. HLM\SYSTEM\ControlSet001\Control\Print\Printers\ 5. HLM\SYSTEM\CurrentControlSet\Control\Print\Printers 6. HCU\Printers\Connections In keinem dieser Schlüssel ist der Drucker aufgeführt. Ich finde diesen über eine Suche in der Registry allerdings in folgenden Schlüsseln: 1. HLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Providers\Client Side Rendering Print Provider\Servers\SRV02\Printers\ 2. HLM\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Print\Providers\Client Side Rendering Print Providers\Servers\SRV02\Printers\ 3. HLM\SYSTEM\ControlSet001\Control\Print\Environments\Windows x64\Drivers\Version-4\ 4. HLM\SYSTEM\ControlSet002\... 5. HLM\SYSTEM\CurrentControlSet\... Stutzig macht mich der Eintrag mit Client Side Rendering Print Provider, SRV02 ist der Printserver im Netzwerk. Kann ich diese Registry Einträge löschen? Was haltet Ihr davon?

Hallo zusammen, mein Problem bezieht sich auf das Vorhandensein eines alten ausrangierten Druckers Laserjet HP, der über Netzwerk eingebunden war. Der Drucker war an einem 2012 R2 Server eingerichtet, bis er vorletzte Woche abgebaut wurde. Dort ist dieser Drucker über eine Benutzer GPO den angemeldeten Remotedesktop-Benutzern zugewiesen worden, sowie den Benutzern, die sich an Phat Client mit Windows 8.1 anmelden. Nun verschwindet dieser Drucker nicht mehr, weder vom Server, noch von den Windows 8.1 Clients, er lässt sich zwar entfernen, ist aber nach einer erneuten Anmeldung wieder da. Ganz gleich welcher Benutzer, sogar das abklemmen vom Netzwerk - getestet mit dem Remotedesktopserver und einem Phat-Client - führt zu der Erstellung eines Gerätes im Gerätemanager unterhalb von Druckwarteschlangen. Nachgestellt habe ich dieses Verhalten mal an einem Win 8.1 Rechner aus einem ganz anderen Netzwerk, der ebenfalls auf Druckerobjekte auf einem Windows 2012 R2 Printserver zugreift. Auch hier kann ich zwar im Gerätemanager das Warteschlangenobjekt entfernen, aber wenn ich dann "nach neuer Hardware suche", wird der Drucker wider erstellt und erscheint auch wieder nutzbar. Ach, der Drucker ist auf dem Printserver ja gar nicht mehr vorhanden. Und obwohl er automatisch unter Drucker und Geräte erstellt wird, ist er nicht auswählbar, wenn ich in irgendeiner Applikation in die Druckerauswahl gehe. Was könnt Ihr mir hierzu sagen? Irgendwas muss ich noch löschen, worauf ich aber nicht komme. Danke und Grüße

Hallöchen, leider muss ich das Thema nochmals aufwärmen. Die Probleme haben sich leider nicht aufgelöst. Folgende Probleme existieren momentan noch: Outlook 2013 meldet beim Einrichten eines neuen E-Mail Profils mit Exchange Konto in der Domäne folgendes: "Fehler beim Anmelden. Überprüfen Sie die Netzwerkverbindung sowie den Server- und Postfachnamen. Es steht keine Verbindung mit Exchange zur Verfügung. Outlook muss im Onlinemodus oder verbinden sein, um diesen Vorgang abzuschließen". Einige bereits eingerichtet Konten über Outlook 2013 keine Kalendereinträge anderer Benutzer sehen, trotz Berechtigung, oder aber Sie können den Abwesenheits Assistenten nicht benutzen. Über OWA funktioniert der Assistent problemlos und ohne Fehler. zu 1.: Wenn ich in die manuelle Konfiguration des Exchange Kontos gehe, dann fehlen bei "Weitere Einstellungen | Verbindungen" sämtliche Einträge bzw. ist erst gar kein Haken gesetzt bei "Verbindung mit Microsoft Exchange über http herstellen. Setze ich den Haken und ergänze die Informationen "Exchange-Proxyserver" mit "remote.kundendomain.com" und "Prinzipalnamen" mit "msstd:remote.kundendomain.com", dann klappt die Verbindung zum Exchange sofort und ohne Probleme. Was muss ich tun, damit diese Einträge auch gesetzt werden? Offensichtlich braucht das Konto die Einstellungen zum Zugriff selbst intern. Von Exchange 2010 bin ich das zwar anders gewohnt, vielleicht liegt aber auch ein Konfigurationsfehler vor? Wäre dankbar für Hilfe. Danke Euch. Mario Problem gelöst. Die Lösung enthalte ich Euch nicht vor. Get-ClientAccessServer | ft Hier war AutoDiscoverServiceInternalUri auf https://remote.kundendomain.com gestanden Set-ClientAccessServer -Identity 'SERVERNAME CAS' -AutoDiscoverServiceInternalUri "https://remote.kundendomain.com/Autodiscover/Autodiscover.xml" Brachte den gewünschten Erfolg. Outlook verbindet sich nun automatisch intern mit dem Postfach, Kalendereinträge sind ebenfalls aus einem anderen Postfach sichtbar und der Abwesenheits-Assistent funktioniert auch.

Hallöchen, nun läuft mein Exchange Server schon einige Wochen und nachdem ich ca. 15 Postfächer anfänglich eingerichtet hatte, wollte ich ein neu erstelltes Postfach in Outlook 2013 einrichten. Nur leider klappt die automatische Einrichtung nicht mehr. Das Postfach wird zwar vom Einrichtungs Assistenten von Outlook 2013 gefunden, kann dann aber mit einer Fehlermeldung nicht final konfiguriert werden. Wie ich festgestellt habe, liegt es an den Exchange-Proxyeinstellungen. Denn trage ich diese in den erweiterten Konfigurationsoptionen ein, dann lässt sich das Postfach problemlos verbinden und funktioniert einwandfrei. Ich hatte an den Einstellung für Autodiscover etwas verändert. Dafür habe in der Domäne im DNS-System eine neue Zone eingerichtet die auf die konfigurierte externe Domain lautet hier remote.domain.de Hierunter befindet sich der Verweis auf den Exchange Server, sprich die interne IP-Adresse des Exchange. Dann habe ich alle virtuellen Verzeichnisse umgestellt. Alle internen und externen URL's verweisen auf remote.domain.de Was fehlt an der Konfig bzw. ist falsch? Muss ich eventuell noch einen SRV-Record für _autodiscover einrichten? Danke und Grüße an Euch. Mario

Danke auch Dir RobertWi. Ist der CAS01 der Exchange Server selber? Ich beantworte meine Frage gleich selber, sorry: Nachdem wir einen Exchange Server mit Client Access haben, ist es in unserem Fall der Exchange Server, der hier zu verwenden ist. Habe den Set-ClientAccessServer Befehl abgesetzt. Wenn ich nun Get-ClientAccessServer -Identity "Cas-01" | ft AutoDiscoverServiceInternalUri eingebe erhalte ich: https://remote.kundendomain.com Die virtuellen Verzeichnisse bis auf Powershell habe ich alle auf https://remote.kundendomain.com angepasst. Sollte es das gewesen sein? Vielen Dank an Euch.

Hi, danke erst mal für Deinen Ansatz. Auf dem DNS-Server existiert bereits eine eigene Zone, die auf den externen Namen lautet, also "remote.kundendomain.com" in der sich wiederum ein Host mit der internen Server IP befindet, das sollte die Split.-DNS Konfiguration sein. Kläre mich bitte auf, wenn ich hier irgendwas falsch verstehe. Pinge ich von intern die externe Url "remote.kundendomain.com" erhalte ich die korrekte interne IP-Adresse zurück. Meinst Du mit URL der virtuellen Verzeichnisse alle? Die sollen dann wohl alle auf "remote.kundendomain.com" laufen und keine Unterscheidung mehr nach intern und extern vornehmen? Grüße

Hallöchen, leider komme ich bei einem Kunden nicht weiter. Das Szenario sieht wie folgt aus: 2012 R2 DC, 2012 R2 Server mit Exchange 2013 Standard, 20 Win 8.1 Pro Client mit Outlook 2013. Ich habe bei DF ein Wildcard Zertifikat geordert, dass auf *.kundendomain.com lautet. Den Antrag hierzu habe ich über die Exchange Verwaltungskonsole durchgeführt. Ausgewählt hatte ich das Platzhalterzertifikat mit der Stammdomäne kundendomain.com Nachdem ich das Zertifikat wieder über die Exchange Verwaltungskonsole eingespielt hatte, fingen die Probleme bei den Clients an. Es erscheint in regelmäßigen Abständen, vor allem aber kurz nach der Anmeldung bzw. dem Öffnen von Outlook, ein Sicherheitshinweis, der mit sagt, dass der Server nicht mit dem Namen der Webseite auf dem Zertifikat übereinstimmt. Das ist auch so bestätigt, denn die Meldung spricht ganz oben in diesem Hinweisfenster von dem internen Server srv05.internedomaene.local und auf dem Zertifikat steht ja der externe Name. Über Get-Outlookprovider bekomme ich als Server srv05.internedomaene.local und Als Prinzipalname msstd:*.kundendomain.com Habe auch schon den Artikel auf www.it-dienstleistungen.de mit dem Thema "MS Exchange Problem: Servername und Name im Zertifikat stimmen nicht überein" durchgearbeitet, allerdings kann ich den Punkt "AutoDiscoverVirtualDirectory" nicht ausführen, da es diese Funktion offensichtlich in Exchange 2013 nicht mehr gibt, wie ich in einem TechNet gelesen habe. Was kann ich tun, damit diese Meldungen endlich verschwinden? Danke und Grüße Mario

Hat denn keiner eine Erklärung dafür?

Softwarelizensierungsdienst-Version: 6.1.7601.17514 Name: Windows Server®, ServerEnterprise edition Beschreibung: Windows Operating System - Windows Server®, OEM_COA_NSLP channel Aktivierungs-ID: xxxxxxxxx Anwendungs-ID: xxxxxxxx Erweiterte PID: xxxxxxxx . . . Lizenzstatus: Lizenziert Verbleibende Windows Rearm-Anzahl: 3 Vertrauenswürdige Zeit: xxxx

@Daniel: Es handelt sich nicht um eine Server Core Installation sondern um eine GUI-Installation. Ich starte das Setup nicht nach einem Neustart, sondern direkt über Windows. Habe aber auch die Installation durch Start der DVD getestet. Auch hier das gleiche Ergebnis, Windows erkennt keine vorhandene Windows Server 2008 R2 Installation.

Hallöchen und schon mal frohe Ostern an alle, der Upgrade Pfad ist im TechNet und im Serverhandbuch von MS zu 2012 R2 beschrieben. Trotzdem habe ich ein Problem bei eben diesem Upgrade. Es handelt sich um eine virtuelle Maschine mit 2008 R2 Enterprise inkl. SP1. Nun wollte ich auf 2012 R2 Standard upgraden. Leider erhalte ich beim starten der ROK Version keine Upgrade Möglichkeit, hier wird nur eine Neuinstallation angeboten. Komisch, denn die installierte 2008 R2 Enterprise Version ist ebenfalls eine ROK Version des gleichen Serverherstellers. Nun dachte ich mir, ich lade mir die Evaluierungsversion herunter und installiere diese. Hier erhalte ich nach dem Starten des Setups zumindest eine nachvollziehbare Fehlermeldung, auch wenn ich diese nicht nachvollziehen kann. Die Meldung lautet: "Windows Server 2008 R2 Enterprise" kann nicht auf "Windows Server 2012 R2 Standard - Testversion (Server mit grafischer Benutzeroberfläche)" aktualisiert werden..." Könnt Ihr mir helfen? Grüße Mario

Hallo, ich stolpere über ein Problem, das Zwischenspeichern von Miniaturansichten in sogenannten thumbs.db Dateien zu unterbinden. Die entsprechende Lokale Benutzereinstellung verteile ich per GPO in "Benutzerkonfiguration -> Administrative Vorlagen -> Windows-Komponenten -> Windows-Explorer -> "Zwischenspeicherung von Miniaturansichten in versteckten thumbs.db-Dateien deaktivieren" an alle Clients. Die Einstellung ist zu aktivieren! Soweit so gut, leider wird bei den Clients diese Einstelllung nicht umgesetzt. Zumindest ist nach Aufruf von gpedit.msc auf einem Windows 7 Pro Client eben genau diese Einstellung nicht aktiviert. Der Status ist immer "nicht konfiguriert". Das verstehe ich nicht. Einen Fehler in der GPO kann ich nicht erkennen. Die Ereignisprotokolle sind ohne Fehler, die Richtlinie wird sauber übernommen. Sehe ich nun unter gpedit.msc einfach nicht die vorgenommen Änderungen oder werden diese nicht übernommen? Grüße Mario

So nun bin ich dem Problem doch auf die Sprünge gekommen. Der Fehler lag an einem fehlerhaften An- und Abmeldeskript, das per GPO in der "Default Domain Policy" den Benutzern zugewiesen war. Hier waren die Serverangaben nicht mehr korrekt. Habe die beiden Skripts gelöscht und in eine separate GPO gepackt. Die Namen des Servers noch korrigiert und dann gpupdate /force durchgeführt. Jetzt rennt alles wieder. MERKE GUT: Nie in die "Default Domain Policy" schreiben!!!!

Fehlermeldungen gibt es sonst keine. Ich habe einen SBS 2011 Standard als DC. Die Gruppenrichtlinien wurden nur um zwei weitere ergänzt. Habe anbei mal ein paar Screenshots der Richtlinien gemacht, die ich sonst noch so im Einsatz habe. Dok1.pdf

Hallo, dieser neue Client ist ein Win7 System Professional. Installiert sind nur die Treiber des Systems. Neu in die Domäne aufgenommen und schon fährt der Rechner erst nach 10 Minuten herunter. Auf den bereits bestehenden Rechnern ist das Problem nicht nach vollziehbar. Auf dem Server läuft als gemeinsame Software Trendmicro Worry Free in der aktuellen Version 7. Diese Software ist aber wie gesagt auf dem problematischen Client nicht installiert. Grüße und vielen Dank.

Hallo bestes Forum, seit einigen Wochen habe ich diese Fehlermeldung auf einem Server 2008 R2 DC. Bei der Abmeldung dauert es genau 559 Sekunden, bis der Server den Benutzer abgemeldet hat. Ebenso lange dauert ein Neustart oder das Herunterfahren. Nun habe ich das Phänomen auch an einem neuen Client Windows 7 Professional 64bit. Bis auf diese Fehlermeldung habe ich keine Events, die auf ein Problem hindeuten könnten. Folgendes habe ich bereits versucht: "Anmeldeskripts gleichzeitig ausführen" in den GPO's aktiviert für Benutzer und Computer. Ebenso habe ich alle Energiefeatures an Windows und der LAN-Karte deaktiviert. Habt Ihr noch Ideen? Grüße Mario

Hallo, wir haben einen neuen SBS2011 in eine bestehende 2003 Domäne integriert. Nun habe ich ein Problem beim Kopieren von Dateien. Genau kann ich nicht sagen, welche Dateien es sind, es sind auch nicht immer die selben Typen. Aufgefallen ist es jetzt ganz aktuell an einer 250 Megabyte PDF Datei. Wenn ein Benutzer versucht, diese mit dem Explorer auf eine der 5 Freigaben auf dem SBS 2011 zu kopieren, dann erscheint die Meldung, dass er dazu Berechtigungen des Administrators benötigt. Wenn ich es als Administrator versuche, dann klappt es. Kopiere ich diese Datei auf eine alte Freigabe des alten 2003 Servers, dann klappt es auch. Habe die Berechtigungen vergleichen, es gibt keine Unterschiede. Selbst wenn ich NTFS Berechtigungen und Freigabeberechtigungen auf JEDER ALLES setze, geht es nicht. In den Fehlerlogs von Win7 und Server 2008R2 (SBS 2011) finde ich keine Hinweise, wen nich das Kopieren starte. Habt Ihr Ideen? Grüße

Hallöchen, habe folgendes Phänomen in meinem Netzwerk. Zweiten DC neben SBS 2011 eingerichtet (AD, DNS). Auf einem Server2003 Standard werden bei der Anmeldung die Gruppenrichtlinien vom zweiten DC geladen, was ich über gpresult herausgefunden habe. Auf einem zweiten Server 2008 R2 mit aktivierten RD Diensten werden die Gruppenrichtlinien vom SBS 2011 geladen,w as ich über gpresult /R herausgefunden habe. Problem: Auf dem 2003 Server wird die Richtlinie "Small Business Server Folder Redirection Policy" angewendet, auf dem 2008 R2 nicht, obwohl die Richtlinie ja im AD vorhaden ist. Wie komme ich da weiter? Grüße und vielen Dank für Eure Hilfe. Mario

Hallöchen, mein Problem besteht in einem Netzwerk mit SBS 2011 Standard. Zusätzlich zu diesem Server existiert unter anderem auch ein W2k8R2 Server mit aktivierter Remotedesktop-Sitzungshost Rolle. Alle Benutzer, die auf dem Remotedesktop-Sitzungshost arbeiten, haben in Ihren Einstellungen unter Active-Directory Benutzer und Computer einen Verweis auf ein servergespeichertes Profil für Remotedesktop-Sitzungen. Wenn ich nun die Ordnerumleitung "Desktop" und "Startmenü" für diese Benutzer aktiviere, wird diese Umleitung auf einem Windows Server 2003 mit aktivierten Terminaldiensten, Windows XP und Windows 7 Clients gemacht. Nicht aber auf dem W2k8R2 Server. Habe versucht die GPO dahingehend anzupassen, dass in den Einstellungen des umzuleitenen Ordners der "exklusive Zugriff" deaktiviert ist. Fehlermeldungen habe ich keine auf dem W2k8R2 Server bei Anmeldung des Benutzers. Komischerweise wird einer ersten Anmeldung am W2k8R2 Server auf dem Share für die umgeleiteten Ordner ein Ordner "documents" angelegt, obwohl ich diesen Ordner gar nicht umleite. Kann mir jemand helfen? Grüße Mario

Hallöchen, komme nicht weiter. Auf dem 2008 R2 Server habe ich dauerhaft Probleme. Seit der Installation passiert es immer wieder, dass unter Tags einfach keine neuen RDP-Verbindungen mehr angenommen werden. Wenn ich in das Fehlerlog sehe, taucht immer wieder die Fehlermeldung 4105 auf. Habe mich nach dem KB Artikel von MS gehalten. Leider kann ich weder "Read Terminal Server License Servers" noch "Write Terminal Server License Servers" finden, somit kann ich diesen Punkt nicht ab arbeiten. Der Server ist auf jeden Fall in der AD-Gruppe der Terminal Server Lizenzserver. Könnt Ihr mir genau sagen, welche Berechtigungen ich da genau setzen muss? Danke für Eure Hilfe. Mario

Leider klappt die Installation der Mailbox Rolle nicht wie gewünscht. Ich erhalte folgenden Fehler: ]# [iD = 8263e07c, Wt = 10, isFatal = True] "Das MSI-Paket fr die Inhaltsindizierung wird installiert." install-MsiPackage -PackagePath ($RoleInstallPath + "Mailbox\MSFTE.MSI") -TargetDirectory $RoleInstallPath -LogFile ($RoleSetupLoggingPath + "\InstallSearch.msilog") -UpdatesDir $RoleUpdatesDir So wie es aussieht ist allerdings alles vorher sauber durchgelaufen. Die Storgages sind auch erstellt. Die Dienste laufen auch sauber. Grüße

Hallo Gabriel70, wie ich feststellen musste, läßt sich die Rolle 'ClientAccess' nach der Deinstallation nicht neu installieren, da das Setup mit einem Fehler abbricht, die Rolle 'Mailbox' wäre nicht konfigriert. Der Aufforderung nach Deinstallation der Mailboxrolle bin ich nachgekommen. Zuerst habe ich alle Mailboxen deaktiviert und dann per adsiedit den öffentlichen Ordner gelöscht. Vorher habe ich natürlich eine Sicherung der EDB's gemacht. Mein Frage ist nun: Wenn ich den Reparaturguide SBS 2008 für die Rolle 'Mailbox' befolgt, ist die Rede davon, die Ordner .\Program Files\Microsoft\Exchange Server\Mailbox\First Storage Group und .\Program Files\Microsoft\Exchange Server\Mailbox\Second Storage umzubenennen, wobei ja davon ausgegangen wird, dass die Mailboxrolle nicht installiert ist. Wenn ich die Rolle 'Mailbox' nun wieder neu installiert habe, kann ich dann die alten EDB's einfach samt Protokolldateien in das neue Folder kopieren oder muss ich eine Recoverygruppe erstellen? Grüße

Hallo, habe ich die Möglichkeit beim SBS 2008 eventuell nur mal die 'ClientAccessRole' neu zu installieren bzw. zu reparieren? Gibt es eine Anleitung für einen reset IIs unter SBS 2008? Wie reinitialisiere ich denn OWA über den System Manager? Grüße