In Exchange 2007 und 2010 sind – anders als in 200/2003 – neue Mail-Verteilergruppen standardmäßig nur intern nutzbar.
Möchte man einen Verteiler einrichten, der von außen per Mail erreichbar ist, muss man dies ausdrücklich einstellen.
Anderenfalls erhält man diese Fehlermeldung:

#550 5.7.1 RESOLVER.RST.AuthRequired; authentication required

Die Umstellung ist ganz einfach:

Um Externe zu erlauben öffnet man in der Exchange-Konsole (GUI) den Verteiler, dort die Registerkarte „Nachrichtenübermittlungseinstellungen“ und dort „Einschränkungen für die Nachrichtenzustellung“. Die dortige Einstellung „Authentifizierung aller Absender anfordern“ ist bei Exchange 2007 und 2010 standardmäßig für neue Gruppen aktiviert. Wenn der Verteiler von außen erreichbar sein soll, muss man den Haken entfernen.

Bei migrierten Gruppen ist dieser Hacken so, wie es in der Vorversion eingestellt war.

Ich habe einen Exchange 2003 nach Exchange 2010 migriert. Alles für das DirectPush richtig eingestellt (ISA, Exchange, IIS..).. aber es funktionierte nicht.
Die Anmeldedatenüberpüfung am iPhone hat geklappt – das abholen der Emails hat mir das iPhone mit einem Fehler quitiert. Bei einem Windows Phone 7 war es ähnlich…

Ursache dieses Problems:

Der Benutzer hatte nach der Exchange-Migration nicht die nötigen Rechte im ActiveDirectory.

Lösung:

Man muss ähnlich vorgehen wie ich hier beschrieben habe.

Die Rechte des ActiveDirectory-Benutzers muss man neu setzen.

Dazu öffnet man auf das Snap-In Active Directory-Benutzer und –Computer und aktiviert unter Ansicht die Erweiterten Funktionen.
Danach wählt man den Benutzer aus, dessen DirectPush nicht funktioniert, und bearbeite die Sicherheitseinstellungen. Man muss in den Sicherheitseinstellungen des Benutzers das Häkchen bei „Vererbbare Berechtigungen des übergeordneten Objekts einschließen“ setzen.

Danach noch einen Moment warten -> dann sollte der Empfang auf dem Handy wieder funktionieren!

Wenn man sich an einer Oracle-Datenbank anmelden will und folgenden Fehler bekommt:

ERROR:
ORA-28000: the account is locked

dann ist der Account gesperrt.
Den kann man ganz einfach wieder entsperren. Anmelden mit einen User mit genügend Rechten (oder mit dem sysdba) und folgendes ausführen:

alter user username account unlock;

Man kann natürlich genau so einen User sperren:

alter user username account lock;

Tipp: Um den Status eines Benutzer anzeigen zu lassen, kann man mittels

select USERNAME,ACCOUNT_STATUS,LOCK_DATE from dba_users where USERNAME=’Test’;

Damit erhält man eine Ausgabe, die wie folgt aussieht:

USERNAME ACCOUNT_STATUS LOCK_DATE
—————————————————————
Test              LOCKED                    14-OCT-10

So hat man einen kleinen Überblick über den Status des Users und seit wann der User gesperrt ist.

Will man – oder eher muss man – auf ein Postfach eines Exchange 2007/2010 per POP3 zugreifen, müssen 3 Schritte gemacht werden, dass das auch funktioniert.

1. POP3-Dienst starten

Standardmäßig ist dieser nicht gestartet. Es reicht, wenn man den Dienst unter der Dienste-Verwaltung (services.msc) einfach startet und auf automatisch setzt. Zu finden ist der unter den ganzen Exchange-Diensten -> Microsoft Exchange POP3

Jetzt funktioniert der Zugriff eigentlich schon. Standardmäßig ist den Benutzern erlaubt, per POP3 Emails abzuholen.

Problem kann sein, dass – weil es z.B. von Benutzern/Rechner ausserhalb der Domäne genutzt wird – das die Anmeldung nicht funktioniert.

Man bekommt: ERR Command is not valid in this state

Dies kann behoben werden, wenn man die Anmeldeeinstellungen des POP3-Dienste ändert.

2. Anmeldeeinstellung des Dienst

In der Exchange Management Shell gibt man den Befehl

Set-PopSettings -LoginType PlainTextLogin

ein.Damit wird die Anmeldeeinstellung des POP3-Dienste auf einfache PlainText-Anmeldung gesetzt.

Damit diese Einstellung noch benutzt werden, muss noch der 3. Schritt ausgeführt werden…

3. POP3-Dienst neu starten

Der POP3-Dienst muss neu gestartet werden, damit die Änderung wirksam wird. Danach kann man sich mit einfacher Angabe des Benutzernamen und Passwort die POP3-Funktionalität nutzen.

Ab jetzt sollte es funktionieren.

Bei einer SBS (Small Business Server) – Migration von SBS 2003 auf 2008 kann es manchmal ja vorkommen, dass man den alten SBS 2003 noch ein wenig weiter laufen lassen will. Das kann verschiedene Gründe haben, z. B. das Datenbanken nicht in der Zeit migriert werden können oder der Druckserver noch weiter verwendet werden soll. Dies ist aber von Microsoft nicht so gewollt. Nach 21 Tagen kommt es zu einem automatischen Neustart des alten SBS-Servers. Das ist natürlich nicht so schön.

Dieses Verhalten wird von dem SBCore-Dienst (C:\WINDOWS\System32\sbscrexe.exe) gesteuert.

Ich hab hier eine Anleitung, wo erklärt wird, wie man dies verhindern kann:

  1. Laden Sie den Process Explorer von Microsoft und starten Sie das Programm
  2. Wählen Sie den Prozess SBCore und suspenden Sie ihn
  3. Öffnen Sie den Registrierungseditor und wählen Sie den Schlüssel HKLM\SYSTEM\CurrentControlSet\Services\SBCore
  4. Öffnen Sie mit der rechtem Maustaste die Eigenschaften des Schlüssels, um die Berechtigungen anzupassen
  5. Geben Sie der lokalen Gruppe Administratorenvolle Berechtigung auf dem Schlüssel und allen untergeordneten Einträgen
  6. Aktualisieren Sie die Ansicht mit F5
  7. Wählen Sie den Parameter Start (DWORD) und ändern Sie die Startart von 2 auf 4 (Deaktiviert)
  8. Öffnen Sie den Windows Explorer und öffnen Sie das Eigenschaftenfenster der Datei C:\WINDOWS\System32\sbscrexe.exe
  9. Verweigern Sie den Zugriff auf die Datei für das Benutzerkonto JEDER (EVERYONE)
  10. Beenden Sie den Prozess über den Process Explorer (Kill)

Wenn der Dienst nicht erneut starten, waren die Änderungen erfolgreich und der Server versieht nun seinen Dienst ohne regelmäßige Neustarts

Quelle: http://www.sf-tools.net/Networking/tabid/56/EntryId/69/SBCore-Dienst-abschalten.aspx

Nach der Anmeldung an einem Windows Server 2008 mit den Remotedesktopdiensten kam die Meldung, das der aktuelle Benutzer nur mit einem temporären Profil angemeldet wurde und das alles Änderungen nach dem Abmelden wieder gelöscht werden.

Bei mir waren da zwei Probleme die zu dem Fehler geführt haben.

1. Problem:

Berechtigungen auf das Profil-Verzeichnis auf dem Terminalserver.

Also hab ich auf C:\Users bzw. C:\Benutzer die Rechte neu vergeben und durchvererbt.

Die Meldung mit dem temporären Profil kam aber wieder..

2. Problem

In der Registry unter

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList

werden für jede Profil Einträge angelegt.
Die alten Einträge werden aber bei einer Neuanlage des Profils nicht überschrieben, somit bekommt der User ein temporäres Profil. Sollange die alten Einträge nicht gelöscht werden, gibts kein anständiges Profil.

Für jeden Benutzer wird ein Schlüssel angelegt, der als Bezeichnung die SID trägt, z. B.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\S-1-5-21-858331090-3027161102-87894692-1004

Unter diesem Schlüssel gibt es einen Wert, den ProfileImagePath – in diesem Wert ist der Pfad zum Profil. Über den Pfad bekommt man den Usernamen raus.

Einfach die Schlüssel der Benutzer löschen die sich nicht sauber anmelden können. Danach werden die Schlüssel neu generiert und dann bekommt der Benuzter bei der nächsten Anmeldung ein sauberes Profil.

Bei der Installation von so mancher Software (in meinem Fall z. B. SQL Server 2008) wird vom Setup überprüft, ob vor der Installation ein Neustart erfoderlich ist.
Hatt auch seinen Sinn, da vielleicht voher Systemdateien geändert worden, etc..
Nur manchmal kannst du das Windows x-fach neustarten, er verlangt immer einen Neustart vor der Installation.

Das liegt meistens an den Registry-Keys:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations

und

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\UpdateExeVolatile

wenn:
der Registrierungsschlüssel UpdateExeVolatile einen anderen Wert als 0 enthält
der Registrierungsschlüssel PendingFileRenameOperations einen beliebigen Wert aufweist

Zur Behebung der Neustart-Problematik muss der Wert UpdateExeVolatile auf 0 gesetzt werden und der Registryeinstrag PrendingFileRenameOperations gelöscht werden.

Bei mir war es meist der Key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations

Quelle: http://technet.microsoft.com/de-de/library/cc164360(EXCHG.80).aspx

Ich hatte das Problem, dass nach einem Update bei jedem Start von iTunes die Abfrage kam: „eingehende Netzwerkverbindung erlauben?

Man konnte noch so oft auf erlauben klicken – die Abfrage kam immer wieder. Auch war iTunes in den Sicherheitseinstellungen der Firewall als erlaubte Anwendung hinterlegt. Manuelles entfernen und hinzufügen – half alles nix.

Hier mal meine Anleitung, wie man diesen Bug wegbekommt:
Mit einem Benutzer anmelden, der Administrationsrechte hat

  1.  iTunes beenden
  2. iTunesHelper beenden -> dazu die Aktivitätsanzeige öffen (entweder über Spotlight oder unter Programme / Dienstprogramme) und den Prozess iTunesHelper in der Prozessliste beenden
  3. Die Firewall-Einstellungen bearbeiten -> dazu unter Einstellungen – Sicherhheit – Registerkarte Firewall unter der Liste der erlaubten Anwendungen iTunes entfernen
  4. iTunes löschen -> dazu im Finder im Ordner Programme iTunes in den Papierkorb ziehen und auch das Dock-Icon entweder in den Papierkorb ziehen (oder Rechtsklick und „aus Dock entfernen“)
  5. iTunesHelper-Startobjekt entfernen -> unter Einstellungen – Benutzer – Startobjekte das Objekt iTunesHelper entfernen
  6. dem Mac neustarten und wieder mit einem Benutzer anmelden, ader Administrationsrechte hat
  7. iTunes runterladen -> auf http://www.apple.com/de/itunes/download/ gibts die aktuelle Version
  8. iTunes installieren und danach NICHT neustarten
  9. iTunesHelper zu den Startobjekten wieder hinzufügen -> im Programm-Ordner mit Rechtsklick (Sekundärklick) auf iTunes und „Paketinhalt zeigen“ auswählen – dann in den Ordner Contents / Resources – dort müsste eine iTunesHelper Datei sein. Das Finder-Fenster auflassen und in die Systemeinstellungen unter Benutzer – Startobjekte die Datei iTunesHelper in die Liste der Startobjekte ziehen und den Haken bei „Ausblenden“ setzten
  10. iTunes starten
  11. iTunes-Dock-Icon per Rechsklick (Sekundärklick) im Dock wieder verankern

Ab jetzt dürfte iTunes nicht mehr nachfragen. iTunes trägt sich automatisch in die Firewall als erlaubte Anwendung ein, da iTunes von Apple signiert ist.

Alle Einstellungen und die Libary bleiben erhalten. Habe keinen negativen Effekt seit der Neuinstallation bemerkt.

Hoffe das klappt bei allen, die das gleiche Problem haben

Ich bin ja ein begeisterter Zuhörer von CRE (ehemals Chaosradio Express) – übrigens auch von den anderen Podcast-Projekten von Tim Pritlove. Mein Tipp: unbedingt reinhören.

Jetzt wollte ich mal eine lose Auswahl von tollen Folgen, die mir sehr gute gefallen haben, hier mal veröffentlichen. Die Reihenfolge ist keine Wertung, sonder wie sie mir einfallen 😉

CRE191 Internet im Festnetz
CRE133 Piraten – Über das Wesen, Unwesen und das soziale Gewissen der Freibeuter der Meere
CRE104 Email – Über das Wesen der elektronischen Post in den modernen Zeiten
CRE100 Das Internet und die Hacker – Ein Blick auf die Anfänge der Internetze und das Wesen des Hackers
CRE144 Die Internetwolke – Ein Blick auf die Infrastruktur des Netzes jenseits der Internetsteckdose
CRE162 Brettspiele – Die Lust der Gesellschaft am Gesellschaftsspiel und dem Spiel mit der Gesellschaft
CRE164 Urheberrecht – Über Rechte, Pflichten, Eigentum und Ansprüche in der digitalen Welt
CRE166 Segeln – Über die erforderliche Technik, Logistik und Einstellung zum Bereisen der Weltmeere

Beim Verschieben eines Postfachs von Exchange 2003 oder 2007 zu Exchange 2010 kann es vorkommen, dass es zu einem Fehler kommt, der folgend lautet:

Fehler:
Fehler bei Active Directory-Vorgang mit xxxxx.xxxxxxx.xx. Bei diesem Fehler ist kein Wiederholungsversuch möglich. Zusätzliche Informationen: Die Zugriffsrechte reichen für diesen Vorgang nicht aus.
Active Directory-Antwort: 00002098: SecErr: DSID-03150BB9, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0.
Der Benutzer verfügt nicht über die erforderlichen Zugriffsrechte.

Der Grund hierfür sind fehlende Berechtigungen des Benutzers im ActiveDirectory.
Man muss in den Sicherheitseinstellungen des Benutzers das Häkchen bei „Vererbbare Berechtigungen des übergeordneten Objekts einschließen“ setzen.

Um diese Option zu editieren, muss im Snap-In Active Directory-Benutzer und –Computer unter Ansicht die Erweiterten Funktionen eingeschaltet sein!

Quelle: http://technikblog.rachfahl.de/technik/fehler-beim-verschieben-eines-exchange-postfachs-von-exchange-2003-zu-exchange-2010/