Outlook PSt ermöglichen trotz GPO-Verbots

[Martin Freiberger]

Hallo,

wir besitzen einen SBS 2003 mit XPSP3 Clients und Outlook2003SP3.

Innerhalb der Domäne ist die Erzeugung von PST-Dateien durch die
Benutzer mittels GPO verboten.


Nach Angabe von z.B.
http://windowsitpro.com/article/articleid/40961/dealing-with-pst-files.html
soll das aber im Bezug auf automatisch erzeugte pst-Dateien folgenden
Effekt haben:

<<Beginning with Outlook 2002 (with Office XP Service Pack
2--SP2--applied) and continuing with Outlook 2003, DisablePST blocks all
user-controlled methods of creating a new .pst file. Setting DisablePST
to 1 prevents all new .pst files except those that Outlook itself
creates for use with IMAP or Hotmail accounts or WSS lists.<<<

Leider ist das nicht der Fall. Verbinde ich eine WSS-Liste (z.B.

Beim Hinzufügen des folgenden Windows Share Point Services Ordners

ist ein Fehler aufgetreten.
Outlook kann den Ordner nicht hinzufügen, da das Erstellen eines neuen
persönlichen Ordners (.pst) auf diesem Computer nicht erlaubt ist.
<<<<

Ich habe nun testweise eine neue Organisationseinheit im AD angelegt und
dieser eine GPO hinzugefügt die die erzeugungt von pst-wieder erlaubt.
In diese Organisationseinheit habe ich dann einen Rechner testweise
verschoben. Hat nichts gebracht.

Dann habe ich auf diesem Rechner den entsprechenden Registryschlüssel
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\11.0\Outlook\DisablePST
manuell auf "0" zurückgesetzt.
Hat auch nichts gebracht.

1te Frage:
----------
Was kann ich nun noch tun? Die automatische Erzeugung von PSt-Dateien
muss funktionieren.

2te Frage:
----------
Wie kann ich den diese Einstellung komplett wieder zurück nehmen? Für
einen anderen RFehler müsste ich nämlich auf einem Rechner mal
kurzfristig wieder eine PSt-Datei erzeugen. Die GPO einfach löschen oder
auf Deaktiviert setzen reicht in diesem Fall wohl nicht aus. Denn ich
habe die GPO nach der Vorlage eines hier bekannten MVPs erzeugt, bei der
sowohl in der Benutzer- als auch Computerkonfiguration der Schlüssel
gesetzt wird. Und im Fall der Computerkonfiguratiuon ist das dann ein
sogenannter "nicht vollständig konfigurierbarer Schlüssel", was wohl
heisst: Wenn der einmal gesetzt wird gibts kein zurück mehr :-(

Vielen Dank

Gruß

[Norbert Fehlauer [MVP]]

"Martin Freiberger" <***@yahoo.de> schrieb
Hi,

Post by Martin Freiberger
----------
Was kann ich nun noch tun? Die automatische Erzeugung von PSt-Dateien muss
funktionieren.

Bei O2k3 weiß ich es grad nicht, aber bei O2k7 gibts dafür explizite pst
Ausnahmen in den adm files.

Post by Martin Freiberger
----------
Wie kann ich den diese Einstellung komplett wieder zurück nehmen? Für
einen anderen RFehler müsste ich nämlich auf einem Rechner mal kurzfristig
wieder eine PSt-Datei erzeugen. Die GPO einfach löschen oder auf
Deaktiviert setzen reicht in diesem Fall wohl nicht aus. Denn ich habe die
GPO nach der Vorlage eines hier bekannten MVPs erzeugt, bei der sowohl in
der Benutzer- als auch Computerkonfiguration der Schlüssel gesetzt wird.
Und im Fall der Computerkonfiguratiuon ist das dann ein sogenannter "nicht
vollständig konfigurierbarer Schlüssel", was wohl heisst: Wenn der einmal
gesetzt wird gibts kein zurück mehr :-(

Da sagt der hier bekannte MVP einfach mal, dass das nicht stimmt. ;) Löschen
hilft tatsächlich nicht, da die Machine Policy eine sogenannte tatooing
policy ist. Dh. du mußt die Policy negieren (deaktivieren) und den PC
einfach neu starten. Danach wird der oben genannte Schlüssel gelöscht (so
hab ich jedenfalls das adm geschrieben). Und dann kannst du auch wieder pst
Dateien auf diesem Computer anlegen.

bye
Norbert

[Martin Freiberger]

Post by Norbert Fehlauer [MVP]
Hi,

Post by Martin Freiberger
----------
Was kann ich nun noch tun? Die automatische Erzeugung von PSt-Dateien
muss funktionieren.

Bei O2k3 weiß ich es grad nicht, aber bei O2k7 gibts dafür explizite pst
Ausnahmen in den adm files.

Ja, dem ist so. Und bei Outlook2003 sollte das das Default-Verhalten
sein, istz es aber leider nicht. Auf jedenfall nicht an diesem Rechner,
an anderen wiederum klappt das :-(

Post by Norbert Fehlauer [MVP]

Post by Martin Freiberger
----------
Wie kann ich den diese Einstellung komplett wieder zurück nehmen? Für
einen anderen RFehler müsste ich nämlich auf einem Rechner mal
kurzfristig wieder eine PSt-Datei erzeugen. Die GPO einfach löschen
oder auf Deaktiviert setzen reicht in diesem Fall wohl nicht aus. Denn
ich habe die GPO nach der Vorlage eines hier bekannten MVPs erzeugt,
bei der sowohl in der Benutzer- als auch Computerkonfiguration der
Schlüssel gesetzt wird. Und im Fall der Computerkonfiguratiuon ist das
dann ein sogenannter "nicht vollständig konfigurierbarer Schlüssel",
was wohl heisst: Wenn der einmal gesetzt wird gibts kein zurück mehr :-(

Da sagt der hier bekannte MVP einfach mal, dass das nicht stimmt. ;)
Löschen hilft tatsächlich nicht, da die Machine Policy eine sogenannte
tatooing policy ist. Dh. du mußt die Policy negieren (deaktivieren) und
den PC einfach neu starten. Danach wird der oben genannte Schlüssel
gelöscht (so hab ich jedenfalls das adm geschrieben). Und dann kannst du
auch wieder pst Dateien auf diesem Computer anlegen.

Naja, am nächsten Morgen gings es dann wirklich endlich. Ich habe jetzt
noch einen Rechner dieser OU zugeordnet. Habe auf dem Server ein
gpupdate /force laufen lassen und den Rechner zweimal neu gestartet. Es
klappt immer noch nicht.

Wie lange dauert es den bis der Rechner merkt das er in einer anderen OU
ist und das neue GPOs gelten? Ist ja nervig :-(



Dazu noch eine Frage zu deiner ADM. Wieso hast du eigentlich die Regel
in die Computerconfiguration gesetzt? Müsste das nicht auch
funktionieren wenn nur in der Benutzerkonfiguration die Regel
existiert? Wäre einfacher handzuhaben.


Gruß

[Winfried Sonntag [MVP]]

Post by Martin Freiberger
Naja, am nächsten Morgen gings es dann wirklich endlich. Ich habe jetzt
noch einen Rechner dieser OU zugeordnet. Habe auf dem Server ein
gpupdate /force laufen lassen und den Rechner zweimal neu gestartet. Es
klappt immer noch nicht.

Hast Du mehrere DCs? Wenn ja, mußt Du die Replikation zwischen den DCs
abwarten, bzw. forcieren. Ein gpupdate /force auf dem Server bringt gar
nichts, denn Du willst die GPO ja auf einen Client wirken lassen.

Post by Martin Freiberger
Wie lange dauert es den bis der Rechner merkt das er in einer anderen OU
ist und das neue GPOs gelten? Ist ja nervig :-(

Wenn alle DCs die geändert GPO bekommen haben, reicht ein Neustart oder
gpupdate am Client vollkommen aus. Hast Du die beiden Einstellungen aus
der GPO-FAQ No. 36 gesetzt?
http://www.gruppenrichtlinien.de/Grundlagen/faq.htm

Servus
Winfried

[Martin Freiberger]

Post by Winfried Sonntag [MVP]
Wenn alle DCs die geändert GPO bekommen haben, reicht ein Neustart oder
gpupdate am Client vollkommen aus. Hast Du die beiden Einstellungen aus
der GPO-FAQ No. 36 gesetzt?
http://www.gruppenrichtlinien.de/Grundlagen/faq.htm

Nee, hatte ich nicht, habe ich aber nun nach geholt. Wobei es in meinem
Fall eh nicht daran liegt, den:
---
Wenn ein Benutzer mit einem servergespeicherten Profil, einem
Basisverzeichnis oder einem Benutzerobjekt-Anmeldeskript sich bei einem
Computer anmeldet, wartet Windows XP immer darauf, dass das Netzwerk
initialisiert ist, bevor der Benutzer angemeldet wird.
---
Wir verwenden sowohl servergespeicherte Profile als auch Basisverzeichnisse.

Ich ahne aber woran der Fehler liegt. Im Ereignisslog steht eine Meldung
das der Domänencontroller nicht zur Verfügung steht. Genauer gesagt sind
es drei Meldungen:

Ereignistyp: Fehler
Ereignisquelle: NETLOGON
Ereigniskategorie: Keine
Ereigniskennung: 5719
Datum: 21.11.2008
Zeit: 11:34:05
Benutzer: Nicht zutreffend
Computer: MyPC3
Beschreibung:
Es steht kein Domänencontroller für die Domäne MyDomain aus folgendem
Grund zur Verfügung:
Es sind momentan keine Anmeldeserver zum Verarbeiten der
Anmeldeanforderung verfügbar. .
Stellen Sie sicher, dass der Computer mit dem Netzwerk verbunden ist,
und versuchen Sie es erneut. Wenden Sie sich an den
Domänenadministrator, wenn das Problem weiterhin besteht.
Weitere Informationen über die Hilfe- und Supportdienste erhalten Sie
unter http://go.microsoft.com/fwlink/events.asp.
Daten:
0000: 5e 00 00 c0 ^..À


Ereignistyp: Fehler
Ereignisquelle: Userenv
Ereigniskategorie: Keine
Ereigniskennung: 1054
Datum: 21.11.2008
Zeit: 11:34:05
Benutzer: NT-AUTORITÄT\SYSTEM
Computer: MyPC3
Beschreibung:
Der Domänencontrollername für das Computernetzwerk konnte nicht
ermittelt werden. (Die angegebene Domäne ist nicht vorhanden oder es
konnte keine Verbindung hergestellt werden. ). Die Verarbeitung der
Gruppenrichtlinie wurde abgebrochen.
Weitere Informationen über die Hilfe- und Supportdienste erhalten Sie
unter http://go.microsoft.com/fwlink/events.asp.


Ereignistyp: Fehler
Ereignisquelle: AutoEnrollment
Ereigniskategorie: Keine
Ereigniskennung: 15
Datum: 21.11.2008
Zeit: 11:34:06
Benutzer: Nicht zutreffend
Computer: MyPC3
Beschreibung:
Die automatische Zertifikatregistrierung für "lokaler Computer" konnte
keine Verbindung zum Active Directory (0x8007054b) herstellen. Die
angegebene Domäne ist nicht vorhanden oder es konnte keine Verbindung
hergestellt werden.
Die Registrierung wird nicht durchgeführt.
Weitere Informationen über die Hilfe- und Supportdienste erhalten Sie
unter http://go.microsoft.com/fwlink/events.asp.

[Winfried Sonntag [MVP]]

Post by Martin Freiberger

Post by Winfried Sonntag [MVP]
Wenn alle DCs die geändert GPO bekommen haben, reicht ein Neustart oder
gpupdate am Client vollkommen aus. Hast Du die beiden Einstellungen aus
der GPO-FAQ No. 36 gesetzt?
http://www.gruppenrichtlinien.de/Grundlagen/faq.htm

Nee, hatte ich nicht, habe ich aber nun nach geholt. Wobei es in meinem

Doch, liegt garantiert dran. Nicht der Punkt mit den Anmeldescripten,
sondern der mit dem Netzwerk:
Computerkonfiguration \ Administrative Vorlagen \ System \ Anmeldung
"Beim Neustart des Computers und bei der Anmeldung immer auf das
Netzwerk warten" = aktiviert
Wenn Du die o.g. Einstellung aktiviert hast, mußt Du den Client 2 x neu
starten. Beim ersten mal übernimmt er die Einstellung, beim zweiten mal
hält er sich dran.

Post by Martin Freiberger
---
Wenn ein Benutzer mit einem servergespeicherten Profil, einem
Basisverzeichnis oder einem Benutzerobjekt-Anmeldeskript sich bei einem
Computer anmeldet, wartet Windows XP immer darauf, dass das Netzwerk
initialisiert ist, bevor der Benutzer angemeldet wird.
---
Wir verwenden sowohl servergespeicherte Profile als auch Basisverzeichnisse.

Trotzdem wird in diesem Fall beim booten nicht auf das Netz gewartet,
sondern bei der Anmeldung. Und das ist ein Unterschied.

Post by Martin Freiberger
Ich ahne aber woran der Fehler liegt. Im Ereignisslog steht eine Meldung
das der Domänencontroller nicht zur Verfügung steht. Genauer gesagt sind

[Fehlermeldungen gesnippt]

Genau die 3 deuten auf das Problem hin. Ist die Client-Zeit mit dem DC
identisch? Wie sieht ein ipconfig /all aus?

Servus
Winfried

[Norbert Fehlauer [MVP]]

"Winfried Sonntag [MVP]" <***@gmx.de> schrieb
Hi,

Post by Winfried Sonntag [MVP]

Post by Martin Freiberger
Nee, hatte ich nicht, habe ich aber nun nach geholt. Wobei es in meinem

Doch, liegt garantiert dran. Nicht der Punkt mit den Anmeldescripten,

Doch wenn die von Martin angesprochenen Faktoren zutreffen, schaltet XP
automatisch die asynchrone Anmeldung ab. ;) Allerdings funktioniert das nach
dem Blinkereffekt. Deswegen bin ich auch dafür auf Domänenebene erstmal
deine Policy zu setzen.

Bye
Norbert

[Winfried Sonntag [MVP]]

Post by Norbert Fehlauer [MVP]
Doch wenn die von Martin angesprochenen Faktoren zutreffen, schaltet XP
automatisch die asynchrone Anmeldung ab. ;) Allerdings funktioniert das nach
dem Blinkereffekt. Deswegen bin ich auch dafür auf Domänenebene erstmal
deine Policy zu setzen.

OK, das sollte eigentlich der Default sein, was ein Admin einstellen
muß. Asynchrones Startverhalten abstellen und das SMB-Signing gem.
BestPraxis konfigurieren. Und keine zusätzlichen PFWs einsetzen.

Servus
Winfried

[Martin Freiberger]

Post by Winfried Sonntag [MVP]

Post by Martin Freiberger

Post by Winfried Sonntag [MVP]
Wenn alle DCs die geändert GPO bekommen haben, reicht ein Neustart oder
gpupdate am Client vollkommen aus. Hast Du die beiden Einstellungen aus
der GPO-FAQ No. 36 gesetzt?
http://www.gruppenrichtlinien.de/Grundlagen/faq.htm

Nee, hatte ich nicht, habe ich aber nun nach geholt. Wobei es in meinem

Doch, liegt garantiert dran. Nicht der Punkt mit den Anmeldescripten,
Computerkonfiguration \ Administrative Vorlagen \ System \ Anmeldung
"Beim Neustart des Computers und bei der Anmeldung immer auf das
Netzwerk warten" = aktiviert
Wenn Du die o.g. Einstellung aktiviert hast, mußt Du den Client 2 x neu
starten. Beim ersten mal übernimmt er die Einstellung, beim zweiten mal
hält er sich dran.

Post by Martin Freiberger
---
Wenn ein Benutzer mit einem servergespeicherten Profil, einem
Basisverzeichnis oder einem Benutzerobjekt-Anmeldeskript sich bei einem
Computer anmeldet, wartet Windows XP immer darauf, dass das Netzwerk
initialisiert ist, bevor der Benutzer angemeldet wird.
---
Wir verwenden sowohl servergespeicherte Profile als auch Basisverzeichnisse.

Trotzdem wird in diesem Fall beim booten nicht auf das Netz gewartet,
sondern bei der Anmeldung. Und das ist ein Unterschied.

Post by Martin Freiberger
Ich ahne aber woran der Fehler liegt. Im Ereignisslog steht eine Meldung
das der Domänencontroller nicht zur Verfügung steht. Genauer gesagt sind

[Fehlermeldungen gesnippt]
Genau die 3 deuten auf das Problem hin. Ist die Client-Zeit mit dem DC
identisch? Wie sieht ein ipconfig /all aus?

OK, ich habe (glaub ich) die Fehlerursache gefunden. Anscheinend liegt
es an der ESET Firewall die auf einigen Client-Rechnern läuft. Die
Rechner bei denen keinerlei Firewall läuft haben die Fehler nicht.

[Winfried Sonntag [MVP]]

Post by Martin Freiberger
OK, ich habe (glaub ich) die Fehlerursache gefunden. Anscheinend liegt
es an der ESET Firewall die auf einigen Client-Rechnern läuft. Die
Rechner bei denen keinerlei Firewall läuft haben die Fehler nicht.

Grmpf, immer diese PFWs. Ich weiß schon, weshalb keine PFW, auch nicht
die von ESET auf meine Rechner kommt. Danke trotzdem für die
Rückmeldung. ;)

Servus
Winfried

[Mark Heitbrink [MVP]]

Hi,

Post by Martin Freiberger
Wie lange dauert es den bis der Rechner merkt das er in einer anderen OU
ist und das neue GPOs gelten? Ist ja nervig :-(

Neustart. Ein Wechsel der OU während der Sitzung wird nicht unterstützt.

Tschö
Mark

[Norbert Fehlauer [MVP]]

"Martin Freiberger" <***@yahoo.de> schrieb
Hi,

Dazu noch eine Frage zu deiner ADM. Wieso hast du eigentlich die Regel in
die Computerconfiguration gesetzt? Müsste das nicht auch funktionieren
wenn nur in der Benutzerkonfiguration die Regel existiert? Wäre einfacher
handzuhaben.

Ähm ich weiß ja nicht, welches adm du nutzt, aber meins kann beides. Wobei
die Nutzerkonfiguration sogar eine echte (blaue) Policy ist.
http://www.gruppenrichtlinien.de/adm/outlookpst.txt

Bye
Norbert

[Martin Freiberger]

Post by Martin Freiberger
Hallo,
wir besitzen einen SBS 2003 mit XPSP3 Clients und Outlook2003SP3.
Innerhalb der Domäne ist die Erzeugung von PST-Dateien durch die
Benutzer mittels GPO verboten.
Nach Angabe von z.B.
http://windowsitpro.com/article/articleid/40961/dealing-with-pst-files.html
soll das aber im Bezug auf automatisch erzeugte pst-Dateien folgenden
<<Beginning with Outlook 2002 (with Office XP Service Pack
2--SP2--applied) and continuing with Outlook 2003, DisablePST blocks all
user-controlled methods of creating a new .pst file. Setting DisablePST
to 1 prevents all new .pst files except those that Outlook itself
creates for use with IMAP or Hotmail accounts or WSS lists.<<<
Leider ist das nicht der Fall. Verbinde ich eine WSS-Liste (z.B.

Beim Hinzufügen des folgenden Windows Share Point Services Ordners

ist ein Fehler aufgetreten.
Outlook kann den Ordner nicht hinzufügen, da das Erstellen eines neuen
persönlichen Ordners (.pst) auf diesem Computer nicht erlaubt ist.
<<<<
----------
Was kann ich nun noch tun? Die automatische Erzeugung von PSt-Dateien
muss funktionieren.

Wie sieht es mit dieser Frage aus? Warum ist es Outlook nicht möglich
automatisch erzeugte pst-Dateien zu erzeugen, obwohl das so in der
entsprechenden GPO steht?

[Norbert Fehlauer [MVP]]

"Martin Freiberger" <***@yahoo.de> schrieb
Hi,

Post by Martin Freiberger

Post by Martin Freiberger
----------
Was kann ich nun noch tun? Die automatische Erzeugung von PSt-Dateien
muss funktionieren.

Wie sieht es mit dieser Frage aus? Warum ist es Outlook nicht möglich
automatisch erzeugte pst-Dateien zu erzeugen, obwohl das so in der
entsprechenden GPO steht?

Wenns bei anderen PCs funktioniert wirds wohl nicht an der Policy liegen ;)

Bye
Norbert

[Martin Freiberger]

Post by Norbert Fehlauer [MVP]
Hi,

Post by Martin Freiberger

Post by Martin Freiberger
----------
Was kann ich nun noch tun? Die automatische Erzeugung von PSt-Dateien
muss funktionieren.

Wie sieht es mit dieser Frage aus? Warum ist es Outlook nicht möglich
automatisch erzeugte pst-Dateien zu erzeugen, obwohl das so in der
entsprechenden GPO steht?

Wenns bei anderen PCs funktioniert wirds wohl nicht an der Policy liegen ;)

Tja, leider scheint es bei allen so zu sein. Auf jeden Fall bei den 5
die ich jetzt überprüft habe. Unter Admin und 2 Benutzer Accounts.

[Wolfgang Krietsch]

Post by Martin Freiberger
Innerhalb der Domäne ist die Erzeugung von PST-Dateien durch die
Benutzer mittels GPO verboten.

Nur aus Neugierde: warum will man das?

Bye

woffi

[Norbert Fehlauer [MVP]]

"Wolfgang Krietsch" <***@nurfuerspam.de> schrieb
Hi,

Post by Wolfgang Krietsch

Post by Martin Freiberger
Innerhalb der Domäne ist die Erzeugung von PST-Dateien durch die
Benutzer mittels GPO verboten.

Nur aus Neugierde: warum will man das?

Dafür kann es mehrere Gründe geben, die teilweise ineinanderlaufen. ;)
Bei Einsatz eines Exchangeservers ist die Auslagerung der Mails in einen
dezentralen Store, wie bspw. pst-Dateien, unpraktisch, da die Daten eben
nicht mehr zentral gesichert werden können. WEiterhin kommt noch dazu, dass
viele Leute nach dieser Aussage anfangen, die pst Dateien auf den Fileserver
zu werfen. Das widerum ist von MS nicht supported.
Abgesehen davon suchen Nutzer ständig ihre pst Dateien wenn sie öfter den
Rechner wechseln. Und welcher Admin hat schon Lust und Muße, ständig die PCs
nach vergessenen pst-Dateien zu durchsuchen.

Reicht dir das als Aussage, oder brauchst du noch mehr? ;)

Bye
Norbert

[Wolfgang Krietsch]

Post by Norbert Fehlauer [MVP]
Dafür kann es mehrere Gründe geben, die teilweise ineinanderlaufen. ;)
Bei Einsatz eines Exchangeservers ist die Auslagerung der Mails in einen
dezentralen Store, wie bspw. pst-Dateien, unpraktisch, da die Daten eben
nicht mehr zentral gesichert werden können. WEiterhin kommt noch dazu, dass
viele Leute nach dieser Aussage anfangen, die pst Dateien auf den Fileserver
zu werfen. Das widerum ist von MS nicht supported.

Oh ... bei uns gibt es sogar die Emmpfehlung, MailArchive auf
Netzlaufwerke iun PST-Dateien auszulagern, damit die Postfächer auf
unserem Exchange Server nicht zu riesig werden (dort gibt's ein 20 MB
Limit für "normale" User). Klappt bisher auch völlig problemlos ...
gibt's einen zwingenden Grund, das abzustellen?

Post by Norbert Fehlauer [MVP]
Reicht dir das als Aussage, oder brauchst du noch mehr? ;)

Reichst mir schon - aber (s. o.) wirft neue Fragen auf.


Grüße

woffi

[Steinsdorfer Walter [MVP Exchange Server]]

Hi,

Post by Wolfgang Krietsch

Post by Norbert Fehlauer [MVP]
Dafür kann es mehrere Gründe geben, die teilweise ineinanderlaufen. ;)
Bei Einsatz eines Exchangeservers ist die Auslagerung der Mails in einen
dezentralen Store, wie bspw. pst-Dateien, unpraktisch, da die Daten eben
nicht mehr zentral gesichert werden können. WEiterhin kommt noch dazu, dass
viele Leute nach dieser Aussage anfangen, die pst Dateien auf den Fileserver
zu werfen. Das widerum ist von MS nicht supported.

Oh ... bei uns gibt es sogar die Emmpfehlung, MailArchive auf
Netzlaufwerke iun PST-Dateien auszulagern, damit die Postfächer auf
unserem Exchange Server nicht zu riesig werden (dort gibt's ein 20 MB
Limit für "normale" User). Klappt bisher auch völlig problemlos ...
gibt's einen zwingenden Grund, das abzustellen?

Post by Norbert Fehlauer [MVP]
Reicht dir das als Aussage, oder brauchst du noch mehr? ;)

Reichst mir schon - aber (s. o.) wirft neue Fragen auf.

20 MB ist aber sehr wenig.
Pst - Dateien haben übrigens die Eigenschaft auch mal kaputt zu gehen wenn
OL das mit dem Schließen beim runterfahren nicht rechtzeitig hinbekommt.
Schon deswegen würde ich das nicht auf den Fileserver legen.

[Wolfgang Krietsch]

Post by Steinsdorfer Walter [MVP Exchange Server]
20 MB ist aber sehr wenig.

Ja, ich weiß. Das stammt noch aus "alten" Zeiten, ist auch noch ein
altes Exchange 5.5, dass demnächst auf (AFAIK) Exchange 2007 geupdated
wird. Exchange ist nicht meine Baustelle, deshalb weiß ich darüber
nicht so viel...

Post by Steinsdorfer Walter [MVP Exchange Server]
Pst - Dateien haben übrigens die Eigenschaft auch mal kaputt zu gehen wenn
OL das mit dem Schließen beim runterfahren nicht rechtzeitig hinbekommt.
Schon deswegen würde ich das nicht auf den Fileserver legen.

Ich werd's mal an die Kollegen weitergeben. Ich habe noch nie gehört,
dass hier solche Probleme auftreten, aber da das nicht mein Ding ist
mag's durchaus sein, dass das an mir vorbeigegangen ist. Danke für den
Hinweis!


Grüße

woffi

[Norbert Fehlauer [MVP]]

"Wolfgang Krietsch" <***@gmx.de> schrieb
Hi,

Post by Wolfgang Krietsch
Oh ... bei uns gibt es sogar die Emmpfehlung, MailArchive auf
Netzlaufwerke iun PST-Dateien auszulagern, damit die Postfächer auf
unserem Exchange Server nicht zu riesig werden (dort gibt's ein 20 MB
Limit für "normale" User).

Wieviele User habt ihr denn? ;)

Post by Wolfgang Krietsch
Klappt bisher auch völlig problemlos ...
gibt's einen zwingenden Grund, das abzustellen?

Wenn dich der fehlende Support und die möglichen Fehler nicht stören, dann
nicht.
http://support.microsoft.com/kb/297019/de

Post by Wolfgang Krietsch
Reichst mir schon - aber (s. o.) wirft neue Fragen auf.

Eigentlich nicht. ;)

Bye
Norbert

[Wolfgang Krietsch]

Post by Norbert Fehlauer [MVP]
Wieviele User habt ihr denn? ;)

ca. 1200.

Post by Norbert Fehlauer [MVP]
Wenn dich der fehlende Support und die möglichen Fehler nicht stören, dann
nicht.
http://support.microsoft.com/kb/297019/de

Danke - das werde ich an die Exchange-Fraktion mal weiterleiten.


Grüße

woffi

[Norbert Fehlauer [MVP]]

"Wolfgang Krietsch" <***@gmx.de> schrieb
Hi,

Post by Wolfgang Krietsch

Post by Norbert Fehlauer [MVP]
Wieviele User habt ihr denn? ;)

ca. 1200.

Auf welchem Exchangeserver? (Edition und Version)

Post by Wolfgang Krietsch
Danke - das werde ich an die Exchange-Fraktion mal weiterleiten.

Mal davon abgesehen belegt man mit pst Dateien mehr Platz auf Serverplatten
als der Exchangestore das tun würde. ;)

Bye
Norbert

[Wolfgang Krietsch]

Post by Norbert Fehlauer [MVP]
Auf welchem Exchangeserver? (Edition und Version)

5.5 SP4 - gab's da schon verschiedene Editionen? Hilfe/Info sagt
nicht mehr dazu.

Post by Norbert Fehlauer [MVP]
Mal davon abgesehen belegt man mit pst Dateien mehr Platz auf Serverplatten
als der Exchangestore das tun würde. ;)

Ja, das mag sein. AFAIR stammt diese Grenze aus einer Zeit, als der
Exchange Server noch auf deutlich kleinerer Hardware lief und arge
PLatzprobleme hatte. Ich schätze mal, dass wir im Rahmen der Migration
auf Exchange 2007 und der Integrations ins AD darüber nochmal
nachdenken werden. Andererseits: nur wenige Leute beklagen sich, dass
die 20 MB zu wenig seien, und ebenfalls nur wenige nutzen die
Möglichkeit, Teile des Postfachs in eine PST Datei auszulagern. So ein
Limit erzieht halt auch zur Ordnung ... ;)


Grüße

woffi

[Martin Freiberger]

Andererseits: nur wenige Leute beklagen sich, dass

Post by Wolfgang Krietsch
die 20 MB zu wenig seien, und ebenfalls nur wenige nutzen die
Möglichkeit, Teile des Postfachs in eine PST Datei auszulagern. So ein
Limit erzieht halt auch zur Ordnung ... ;)

Unglaublich. Eure Leute sind nicht gerade kommunikativ zu nennen. Wir
haben als Default-Postfachgröße 220MB und das wird von einer ganzen
Reihe User sehr schnell überschritten und locker mal auf das 20fache
aufgebläht. Aber das machen halt die vielen, vielen großen Dateianhänge
die versendet und empfangen werden. Die werde ich in nächster Zukunft
wohl auslagern, dann hat sich das auch erledigt.

[Wolfgang Krietsch]

Post by Wolfgang Krietsch
Andererseits: nur wenige Leute beklagen sich, dass

Post by Wolfgang Krietsch
die 20 MB zu wenig seien, und ebenfalls nur wenige nutzen die
Möglichkeit, Teile des Postfachs in eine PST Datei auszulagern. So ein
Limit erzieht halt auch zur Ordnung ... ;)

Unglaublich. Eure Leute sind nicht gerade kommunikativ zu nennen.

Wir sind eine Behörde - glaub mir, die sind kommunikativ ;)

Aber große Dateianhänge gibt's bei uns nicht sooo häufig bei normalen
Anwendern, und für nur-Text-Mails sind 20 MB schon eine Menge, wenn
man unwichtigen/veralteten Kram löscht.


Grüße

woffi

[Norbert Fehlauer [MVP]]

"Wolfgang Krietsch" <***@gmx.de> schrieb
Hi,

Post by Wolfgang Krietsch

Post by Norbert Fehlauer [MVP]
Auf welchem Exchangeserver? (Edition und Version)

5.5 SP4 - gab's da schon verschiedene Editionen? Hilfe/Info sagt
nicht mehr dazu.

Ja auch bei 5.5 gabs schon Standard und Enterprise Editionen.

Bye
Norbert

[Martin Freiberger]

Post by Martin Freiberger
Hallo,
wir besitzen einen SBS 2003 mit XPSP3 Clients und Outlook2003SP3.
Innerhalb der Domäne ist die Erzeugung von PST-Dateien durch die
Benutzer mittels GPO verboten.
Nach Angabe von z.B.
http://windowsitpro.com/article/articleid/40961/dealing-with-pst-files.html
soll das aber im Bezug auf automatisch erzeugte pst-Dateien folgenden
<<Beginning with Outlook 2002 (with Office XP Service Pack
2--SP2--applied) and continuing with Outlook 2003, DisablePST blocks all
user-controlled methods of creating a new .pst file. Setting DisablePST
to 1 prevents all new .pst files except those that Outlook itself
creates for use with IMAP or Hotmail accounts or WSS lists.<<<
Leider ist das nicht der Fall. Verbinde ich eine WSS-Liste (z.B.

Beim Hinzufügen des folgenden Windows Share Point Services Ordners

ist ein Fehler aufgetreten.
Outlook kann den Ordner nicht hinzufügen, da das Erstellen eines neuen
persönlichen Ordners (.pst) auf diesem Computer nicht erlaubt ist.
<<<<
Ich habe nun testweise eine neue Organisationseinheit im AD angelegt und
dieser eine GPO hinzugefügt die die erzeugungt von pst-wieder erlaubt.
In diese Organisationseinheit habe ich dann einen Rechner testweise
verschoben. Hat nichts gebracht.
Dann habe ich auf diesem Rechner den entsprechenden Registryschlüssel
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\11.0\Outlook\DisablePST
manuell auf "0" zurückgesetzt.
Hat auch nichts gebracht.
----------
Was kann ich nun noch tun? Die automatische Erzeugung von PSt-Dateien
muss funktionieren.

nach langer Sucherei habe ich den Fehler gefunden.

Es fehlt ein Regystriewert der von der Vorlage nicht gesetzt wurde.

Siehe dazu http://support.microsoft.com/kb/897658/de

------
Beenden Sie Outlook 2003.
Auf Start klickt Sie, klicken Sie auf Ausführen, Typ regedit, Und dann
klicken Sie auf OK.
Klicken Sie auf folgenden Unterschlüssel in der Registrierung:
HKEY_LOCAL_MACHINE\Software\Microsoft\Office\11.0\Outlook
Zeigen Sie auf Neu in dem Menü Bearbeiten und klicken Sie anschließend
auf DWORD-Wert, nachdem Sie auf den Unterschlüssel klicken, der in
Schritt 3 angegeben wird.
Typ AlwaysAllowSharePointPST, Und die EINGABETASTE dann drückt.
Klicken Sie mit der rechten Maustaste auf AlwaysAllowSharePointPST, und
klicken Sie dann auf Ändern.
Geben Sie in dem Feld Wert ein 1, Und dann klicken Sie auf OK.
Klicken Sie in dem Menü Datei auf Beenden, um Registrierungseditor zu
beenden.
----

Jetzt funktioniert die Sache. Die User können keine PST-Dateien erzeugen
aber man kann trotzdem Sharepoint-Kalender mit Outlook verknüpfen.

[Norbert Fehlauer [MVP]]

"Martin Freiberger" <***@yahoo.de> schrieb
Hi,

Post by Martin Freiberger
nach langer Sucherei habe ich den Fehler gefunden.
Es fehlt ein Regystriewert der von der Vorlage nicht gesetzt wurde.
Siehe dazu http://support.microsoft.com/kb/897658/de

Danke für die Rückmeldung.

Bye
Norbert

[Martin Freiberger]

Post by Norbert Fehlauer [MVP]
Hi,

Post by Martin Freiberger
nach langer Sucherei habe ich den Fehler gefunden.
Es fehlt ein Regystriewert der von der Vorlage nicht gesetzt wurde.
Siehe dazu http://support.microsoft.com/kb/897658/de

Danke für die Rückmeldung.

Aktualisiert du deine Vorlage um diesen Wert? Wäre nett, ansonsten muss
ich das mit den Registryschlüsseln per GPO verteilen halt mal selber
hinbekommen.

[Norbert Fehlauer [MVP]]

"Martin Freiberger" <***@yahoo.de> schrieb
Hi,

Post by Martin Freiberger
Aktualisiert du deine Vorlage um diesen Wert? Wäre nett, ansonsten muss
ich das mit den Registryschlüsseln per GPO verteilen halt mal selber
hinbekommen.

Kann ich machen. Würdest du das für mich testen können?

Bye
Norbert

[Martin Freiberger]

Post by Norbert Fehlauer [MVP]
Hi,

Post by Martin Freiberger
Aktualisiert du deine Vorlage um diesen Wert? Wäre nett, ansonsten
muss ich das mit den Registryschlüsseln per GPO verteilen halt mal
selber hinbekommen.

Kann ich machen. Würdest du das für mich testen können?

Ja, kann ich machen. Schick mir die Vorlage grad an diese E-Mail Adresse.

Danke & Gruß