phboos

Hallo Zusammen, ich habe ein kleines Problem, für das ich noch auf der Suche nach einer Lösung bin, vielleicht hat ja jemand eine Idee, wie es zu lösen ist: In einer Domäne wird ein SCDPM 2012 für die Sicherung von Notebooks/Laptops eingesetzt, die zu sichernden Systeme sind in entsprechenden Schutzgruppen organisiert. Die Synchronisierung, Konsistenzprüfung und Wiederherstellungszeitpunkte etc. funktioniert alles. Jetzt zu dem Problem/Aufgabe: Laptops im lokalen Netz sollen normal gesichert werden, die Datenmenge spielt keine Rolle, wenn ein User aber per VPN verbunden ist, soll nur die Synchronisierung stattfinden, aber keine Konsistenzprüfung, wie kann dieses eingestellt werden? ich finde nur eine eine Client basierte Bandbreitenbegrenzung mit Unterschied Arbeitszeit/nicht Arbeitszeit. Ich möchte ungern eine komplette Konsistenzprüfung mit mehreren GB bei Usern durchführen, die gerade per UMTS/VPN verbunden sind. Eine Option, beispielsweise die IPs des Einwahlnetzwerkes auszuwählen habe ich noch nicht gefunden. Hat jemand hierfür eine Idee? danke phboos

Hi, danke für die Links, kurzfristig heisst bei mir nicht heute Abend sondern in den nächsten ein bis zwei Wochen, sowie nach ein wenig lektüre dazu. Vor solchen Umstellungen gibt es dann auch nen Snapshot aller Maschinen für den Fall der Fälle @Norbert: auch mit solchen Sachen bist du vor den schnellen Klicks bei unüberlegten Leuten nicht gefeit, vorallem nicht, wenn dir niemand etwsa über sein "missgeschick" erzählt und du die scherben irgendwie aufkehren musst

Hi Mr_Marple, danke für die Hinweise, das mit dem Hygiene Eintrag fehlte noch sowie der Neustart, nun funktioniert die ganze Verwaltung wieder korrekt Der AD Papierkorb ist leider noch nicht aktiviert gewesen auf den beiden DC (2008 R2), das werde ich jetzt aber kurzfristig nachholen. Soweit läuft nun alles wieder, vielen Dank

Hi, danke für die Auflistung, im Hygiene Management fehlte noch das Konto, Fehlermeldung war eben noch da, Neustart geht leider erst heute Abend. Im AD Papierkorb muss ich nachher in einer ruhigen Minute nochmal schauen, vielleicht ist da doch noch was vorhanden

Hi, ganz einfach leider nicht, ein Admin hat sich im DC "verklickt" und das falsche Computerkonto gelöscht, niemanden bescheid gesagt und den Server wieder neue in die Domäne genommen. Anfangs ist auch nichts aufgefallen, das E-Mail/Exchange noch normal funktioniert, alle User können sich anmelden etc. Auch der Administrator kann sich in die Exchange Verwaltungskonsole einloggen, sieht alle Optionen, nur beim ausführen der Befehle (egal welchen) kommt nun die Fehlermeldung. Exchange "sieht" aber noch das komplette AD, wenn ich im AD ein neues Userkonto anlege, kann ich in Exchange dieses auch auswählen um dort ein E-Mail Postfoch draus zu machen, nur beim ausführen des anlege Befehls scheitert er dann wieder. Grade eine echt doofe Sache, ist dieses nur ein "Berechtigungsproblem" das der Administrator aus einigen Gruppen "geflogen" ist? Oder muss Exchange komplett neu installiert werden, aber die Domäne weiterhin nutzbar ist? Es sind nur knapp über ein Dutzend Postfächer drauf, allerdings mit knapp 10 GB Postfachspeicher danke für eure Vorschläge

Hallo Zusammen, ich habe ein kleines/großes Problem derzeit, unser Exchange 2010 Server hat letztens sein Computer Konto in der AD verloren und ging nur über den Weg AD-Member -> Workgroup -> AD Member wieder ans laufen zu bringen. Leider habe ich nun einige Probleme, Exchange an für sich läuft noch, allerdings kann ich in der Exchange Veraltungskonsole keinerlei Aktionen mehr durchführen (Verteilergruppe anlegen, User Postfach deaktivieren etc.), das normale Arbeiten mit Exchange funktioniert jedoch ohne Probleme. Die Fehlermeldung die kommt sieht folgendermaßen aus: Fehler: Fehler bei Active Directory-Vorgang mit dc01.domain.de. Bei diesem Fehler ist kein Wiederholungsversuch möglich. Zusätzliche Informationen: Zugriff verweigert. Active Directory-Antwort: 00000005: SecErr: DSID-031521D0, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0 . Der Benutzer verfügt nicht über die erforderlichen Zugriffsrechte. Ausführungsversuch eines Exchange-Verwaltungsshellbefehls: new-DistributionGroup -Name 'verteiler' -Type 'Distribution' -SamAccountName 'Verteiler' -Alias 'Verteiler' Verstrichene Zeit: 00:00:00 in der Ereignissanzeige finde ich ein wenig mehr infos: (PID 4480, Thread 2371) Task 'New-DistributionGroup' schreibt beim Verarbeiten des Datensatzes von Index 0 einen Fehler. Fehler: Microsoft.Exchange.Data.Directory.ADOperationException: Fehler bei Active Directory-Vorgang mit dc01.domain.de. Bei diesem Fehler ist kein Wiederholungsversuch möglich. Zusätzliche Informationen: Zugriff verweigert. Active Directory-Antwort: 00000005: SecErr: DSID-031521D0, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0 . ---> System.DirectoryServices.Protocols.DirectoryOperationException: Der Benutzer verfügt nicht über die erforderlichen Zugriffsrechte. bei System.DirectoryServices.Protocols.LdapConnection.ConstructResponse(Int32 messageId, LdapOperation operation, ResultAll resultType, TimeSpan requestTimeOut, Boolean exceptionOnTimeOut) bei System.DirectoryServices.Protocols.LdapConnection.SendRequest(DirectoryRequest request, TimeSpan requestTimeout) bei Microsoft.Exchange.Data.Directory.PooledLdapConnection.SendRequest(DirectoryRequest request, LdapOperation ldapOperation, IAccountingObject budget) bei Microsoft.Exchange.Data.Directory.ADSession.ExecuteModificationRequest(ADObject entry, DirectoryRequest request, ADObjectId originalId, Boolean emptyObjectSessionOnException) --- Ende der internen Ausnahmestapelüberwachung --- bei Microsoft.Exchange.Data.Directory.ADSession.AnalyzeDirectoryError(PooledLdapConnection connection, DirectoryRequest request, DirectoryException de, Int32 totalRetries, Int32 retriesOnServer) bei Microsoft.Exchange.Data.Directory.ADSession.ExecuteModificationRequest(ADObject entry, DirectoryRequest request, ADObjectId originalId, Boolean emptyObjectSessionOnException) bei Microsoft.Exchange.Data.Directory.ADSession.Save(ADObject instanceToSave, IEnumerable`1 properties) bei Microsoft.Exchange.Data.Directory.Recipient.ADRecipientSession.Microsoft.Exchange.Data.IConfigDataProvider.Save(IConfigurable instance) bei Microsoft.Exchange.Configuration.Tasks.SetTaskBase`1.InternalProcessRecord() bei Microsoft.Exchange.Configuration.Tasks.NewTaskBase`1.InternalProcessRecord() bei Microsoft.Exchange.Configuration.Tasks.NewADTaskBase`1.InternalProcessRecord() bei Microsoft.Exchange.Configuration.Tasks.Task.ProcessRecord() Für Vorschläge wäre ich dankbar

Hi, ich habe ein Problem mit meinem Exchange 2007 Server, am Wochenende gabs ein paar Updates von MS, wo er ein wenig "husten" bekommen hat. So waren nach dem Neustart nach dem Update sämtliche Exchange Dienste noch auf "disabled" in den Services, gut, die kann man ja wieder aktiv setzen. Das größere Problem ist aber der OWA, der kein "Design" mehr anzeigt, also nur noch schwarze Schrift auf weißem Grund, ohne Formatierungen, Bilder etc. und damit nicht mehr nutzbar ist. Ich habe bereits über die Powershell einmal das OWA Verzeichnis gelöscht und wieder neu gesetzt (keine Verbesserung) Irgendjemand noch eine Idee? Die Board Suche bringt mir nur das OWAVirtual Directory was ich bereits gemacht habe oder halt infos über Probleme bei einem einzelnen User. Intern geht das Exchange noch mit Outlook 2007, ebenso ActiveSync über das Internet zu den Mobile Devices, nur die WebOberfläche ist halt "Zerschossen" bzw. sieht aus, als ob die CSS Dateien für die Formatierung fehlen. – so, step by step geht es voran.... das problem scheint im letzten Update zu liegen, da hier etliche Ordner leer sind, bzw. nur eine datei vorhanden ist: ClientAccess/8.1.340.0/themes/base/ nachdem ich aus der vorherigen Version die Dateien übernommen habe, gehen schonmal die Designs wieder, aber das Arbeiten funktioniert immer noch nicht korrekt. So geht zwar das anmelden, aber danach ist keine weitere sinnvolle nutzung mehr möglich. Kein klick löst mehr eine Reaktion aus.

so, zu deinen Fragen: OEA funktioniert ohne Sicherheithinweis, unter der "normalen" adresse ex01.myfirm.de sowie autodiscover.myfirm.de outlook kommt mit einer PW Abfrage Box Authetizierung bei Outlook? an welcher stelle sehe ich die? unter den konteneinstellungen habe ich nur das hier gefunden: Unter Sicherheit / Netzwerksicherheit bei Anmeldung habe ich sowohl Aushandlungsbasiert, als auch NTLM probiert Unter Verbindung habe ich unter erweiterte Proxy Einstellungen auch Standard und NTLM probiert.... er versucht sich zu verbinden und dann kommt immer getrennt Als Proxy Server steht dort autodiscover.myfirm.de drin, bzw. msstd:autodiscover.myfirm.de

ich hab es nun endlich ans laufen gebracht, war etwas tricky, da er irgendwie über die power shell das zertifikat nicht importieren wollte. Über eine neue CSR, die vom IIS generiert wurde und nen Re-Key bei der Zertifikatsstelle konnte ich es dann aber erfolgreich einrichten. nur autodiscover/anywhere will er irgendwie immer noch nicht machen :-( Ich habe anywhere aktiviert und auch die externen Verzeichnisse eingestellt, im Autodiscover-Test zeigt er mir das auch an, aber er verbindet mir mein outlook nicht. Die Frage ist warum? Das Outlook wurde direkt in der Domäne synchronisiert, ist aber seit 14 Tage dort nicht mehr angemeldet gewesen (laptop außer Haus auf Reisen) kann es daran liegen?

@brainstorm danke für den link allerdings hab ich da ein kleines Problem, das crt File was ich zurück bekomme krieg ich im IIS irgendwie nicht ans laufen, ich hab es in meinen keystore importiert, kann es auch im IIS auswählen, aber ansprechen kann ich den server auf dem port nicht Ich habe ein Zertifikat das alle Domains abdeckt, die ich brauche (5 Stück), neben ex01.myfirm.de, autodiscover.myfirm.de, ex01.myfirm.local, autodiscover.myfirm.local und auch ex01 ohne domainnamen aber ich krieg aufm 443 einfach keinen connect hin, sobald ich das Zertifikat austausche gegen das alte, geht es wieder.... Im Keystore zeigt er es mir auch korrekt an (kompletten Cert Pfad ohne Fehler), irgendeine Idee? Im Firefox bekomme ich immer:

ihr seit einfach zu schnell hier für mich ;-) intern eine lookupzone zusätzlich einrichten finde ich nicht unbedingt als gute idee, da wir etliche hosts noch drin haben, die unter der offiziellen myfirm.de erreichbar sind (Router, Firewalls, Webserver... was man so hat) dieses sowohl auf den internen DNS als auch auf den Provider DNS zu pflegen birgt da ein wenig probleme, das diese auch immer beide das gleiche machen daher schon lieber mit den beiden unterschiedlichen Zonen für intern local und für extern die .de

danke für die schnelle antwort, die SAN Zertifikate sind mir bereits ein begriff glaube habe eher noch was vergessen in meinem post, ich will halt auch über autodiscover per https entfernte outlooks konfigurieren, den "erstkontakt" kriegen diese auch über autodiscover.myfirm.de/Autodiscover/Autodiscover.xml Jedoch in der Antwort immer nur die interne URL angegeben zur kommunikation, jedoch nicht die externe, hier mal der auszug aus dem E-Mail Autokonfigurations Test von Outlook 2007: Protocol: Exchange RPC Server: ex01.myfirm.local Login Name: xxxx Availability Service URL: https://ex01.myfirm.local/EWS/Exchange.asmx OOF URL: https://ex01.myfirm.local/EWS/Exchange.asmx OAB URL: https://ex01.myfirm.local/OAB/..... Unified Message Service URL: https://ex01.myfirm.local/UnifiedMessaging/Service.asmx Auth Package: Unspecified Protocol: Exchange HTTP Server: autodiscover.myfirm.de Login Name: xxxx SSL: Yes Mutual Authentication: Yes Auth Package: Basic Certificate Principal Name: msstd.autodiscover.myfirm.de Was mich wundert ist, das er hier HTTP nutzt und nicht HTTPS, dies könnte aber daran liegen, das das ZErtifikat vor 2 Monaten abgelaufen ist oder halt nicht für autodiscover.myfirm.de ausgestellt ist sondern für ex01.myfirm.local ich habe bereits über die Powershell versucht eine andere externe URL für AutodiscoverVirtualDirectory zu setzen, diese will er aber irgendwie auch nicht, ein get-AutodiscoverVirtualDirectory gibt folgendes aus: Name : Autodiscover (Default Web Site) InternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated} ExternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated} BasicAuthentication : True DigestAuthentication : False WindowsAuthentication : True MetabasePath : IIS://ex01.myfirm.local/W3SVC/1/ROOT/Autodiscover Path : C:\Program Files\Microsoft\Exchange Server\ClientAccess\Autodiscover Server : EX01 InternalUrl : https://ex01.myfirm.local/Autodiscover/Autodiscover.xml ExternalUrl : https://ex01.myfirm.de/Autodiscover/Autodiscover.xml AdminDisplayName : ExchangeVersion : 0.1 (8.0.535.0) DistinguishedName : CN=Autodiscover (Default Website),CN=HTTP,CN=Protocols,CN=EX01,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=First Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=myfirm,DC=local Identity : EX01\Autodiscover (Default Web Site) Guid : 453b736a-fc19-41f3-9498-a70cfa77d381 ObjectCategory : myfirm.local/Configuration/Schema/ms-Exch-Aut o-Discover-Virtual-Directory ObjectClass : {top, msExchVirtualDirectory, msExchAutoDiscove rVirtualDirectory} WhenChanged : 16.01.2009 18:16:44 WhenCreated : 15.11.2007 14:23:51 OriginatingServer : srv12.myfirm.local IsValid : True srv12 ist ein lokaler DNS Server, im externen DNS stimmt die auflösung auf die NAT Adresse Hoffe ich hab nun mein anliegen etwas genauer geschildert

Hallo, ich hab mir jetzt schon nen wolf gesucht und entweder ich suche falsch oder es gab die frage bisher noch nicht, folgende Situtation: Ich habe hier einen Exchange 2007 Server in einer rein Windows 2003 AD Domäne, diese wurde entsprechend unter dem domänennamen myfirm.local aufgesetzt. Der Exchange Server ist entsprechend auch unter ex01.myfirm.local im internen Netz erreichbar. Nun möchte ich ein offizielles SSL Zertifikat für die interne als auch externe Kommunikation mit dem Exchange haben. Von außen wird jedoch über die Domain myfirm.de zugegriffen. Wie stelle ich dieses nun am sinnvollsten an. Der Server hat intern eine private IP Adresse 192.168.x.x und extern wird diese auf eine offizielle genattet. Am schönsten wäre es, ein Zertifikat zu nutzen, welches zum einen autodiscover.myfirm.de und ex01.myfirm.de (für OWA) abdeckt. Durch myfirm.local im internen wird dieses aber probleme bringen. Hat jemand eine Idee, wie ich dieses lösen kann? Die Domäne komplett umstellen von myfirm.local auf myfirm.de? Für Ideen bin ich gerne zu haben. Achja,bevor ich es vergesse, als Clients kommen Outlook 2007 mit SP1 sowie iPhones zum einsatz, bzw. IE und Firefox für OWA danke schonmal

Hi, danke für die schnellen infos, einiges an Zeit haben wir bereits "rausgeholt" der Web Adapter der Fritz Card PCI v2 war dran schuld, den rest dürften wir durch ein wenig tuning im DNS des DC hinbekommen, derzeit liegt die zeit wieder in annehmbaren 2 Minuten nach dem Login Schirm. Mit den DNS Sachen werden wir auch nochmal schauen.

Hi, habe ein kleines problem derzeit: Auf einem recht frischen Windows XP Pro SP1 in einer Windows 2003 Domäne dauert die Nutzeranmeldung knappe 11 Minuten (nach Eingabe Nutzername/Passwort), das Profil selber ist nicht so groß, knappe 100 MB, Verbindung über GigaBit Ethernet. Wenn der Rechner ohne Domäne hochfährt, ist alles ziemlich fix, nur eben mit hat er so seine Probleme (lange Wartezeit) Der Rechner selber hat noch so einige besonderheiten: Drei Schirm Arbeitplatz AVM ISDN PCI v2 mit 3.0.2 Fritz Software (evtl. hier der virtuelle Netzwerktreiber) Bluetooth Dongle Exchange Postfach mit knapp 2 GB Volumen (wird aber erst nach der Anmeldung gestartet) Jemand ne Idee, wo man ansetzen kann? Der Rechner ist keine 48 Stunden alt von der Installation, auch die Ausstattung sollte reichen (512 MB RAM, aktueller Desktop Prozessor 2 Ghz), andere auch langsamere Systeme melden sich um einiges schneller am System an.... Nur dieser eine Rechner hat seine Probleme. Das Profil existierte schon vorher für nen anderen Arbeitsplatz, der furh aber auch in unter 4 min komplett hoch. danke schonmal im voraus