Issue with PST files on W2K3 server

[CSCKone]

We have just moved from a NT 4 server to a Windows 2003 server for our file/print server at a branch location. We are still on an NT 4 domain for the next 9 months until our AD project is completed.

All of the users have a home directory located on this server. Since the move, users have complained of their PSTs losing connection and generating a "Unable to display the folder. You do not have sufficient permission to perform this operation on this object. See the folder contact or your system administrator" message.
To correct this, they have to log off and back on.

To this point, I have increased the autodisconnect time to about 8 hours. This didn't help the situation.
The server does seem to have a lot of processor activity due to some of the print applications (Lanier etc), but since I am not on-site, I can't verify if they are occuring while the disconnects happen, and our on-site person says they don't seem to be related.

Has anyone encountered anything similar or have any suggestions to try?

Any help is much appreciated, as I'd rather not roll back to NT 4 or Win2K

 

[adcfaq]

Obviously, when u migrated the file server, you didn't migrate the ACLs, or you didn't migrate the users SIDHistory from NT to AD.

You tell me which one, and what tools you used to migrate to AD, and I will let u know a workround.

---------------------------------------
Sr. Directory Services/Exchange Consultant

http://adcfaq.8m.com/

 

[CSCKone]

We are still on an NT 4 domain, as I mentioned, so AD shouldn't be a factor.

We have also recreated some of the shares, to rule that out.

 

[PScottC]

The default permissions at the Share level are different between NT4 and 2003. Even if you correctly brought the NTFS permissions over, you probably need to correct the share level permissions.

NT4 = All Users : Full Control
2003 = All Users : Read

Change the share level permissions on the 2003 box to All Users : Full Control.

NTFS will limit access as it did on your NT4 server.

PSC

Governments and corporations need people like you and me. We are samurai. The keyboard cowboys. And all those other people out there who have no idea what's going on are the cattle. Mooo! --Mr. The Plague, from the movie "Hackers

 

[CSCKone]

There are no NTFS permissions on the folders, just share level

Our shares are setup as \\servername\username$
With the user of the share setup as Full Control, and no one else having share permissions.

Would you suggest changing this to NTFS on the folder level and open the share to everyone full control?

 

[PScottC]

Setting your permissions that way is recommended by Micorsoft. You have much more granular control over NTFS than you do at the share level.

But... If this is how you had it set up before then leave it. You have enough going on with your migration. You will want to fix it in the future.

At this point check the NTFS permissions on the directories and make sure that "Everyone" or "Authenticated Users" is given Full (or at least Modify) rights.

PSC

Governments and corporations need people like you and me. We are samurai. The keyboard cowboys. And all those other people out there who have no idea what's going on are the cattle. Mooo! --Mr. The Plague, from the movie "Hackers

 

[KingSalkir]

What version of Outlook client are you running? If you are also running Outlook 2003 there is an incompatiblity with older .PST files. If this is the case you need to recreate the .PST files for Outlook 2003 and then remove the old ones.

 

[CSCKone]

The OS's are

XP XP2 - Outlook and Office 2000 SP3
All of the rest are Windows 2000 SP4, with Office/Outlook 2000 with SP3

 

[KingSalkir]

What version of Exchange are you running?

I would try a test on a .PST rebuild and see if that helps.

 

[CSCKone]

We have rebuilt some of the PSTs to no effect. We also moved the users to another 2003 server, to make sure it wasn't a hardware issue (the home directory server also has some printer software which seems to chew up processor.)

The tested users had the same issue on both servers, with recreated PSTs.

I am in the process of changing to Folder level permissions and Everyone full control on the share.

We use Exchange 5.5 for the time being.

 

[CSCKone]

Changed to folder level permissions, same issue. No change whatsoever

 

[NickFerrar]

Hmm pretty odd problem, we have a very similar environment but don't get the issue (unless the server reboots ).

Do all your users get disconnected from their PSTs at the same time? Might be worth doing a continuous ping to the server and making sure it's not dropping off the network momentarily from time to time (this can happen with certain NIC/switch combos IME). We also get a problem with McAfee AV v8 on servers - unless you apply patch 10 it can cause NetBIOS to fail on the server every so often (ping still works but you can't use mapped drives etc.).

I'd first try to establish if there's a pattern to the disconnects and go from there.

 

[dccs]

I got the same issue.
The user has full control on file and share level but the connection to the PST file is dropped occasionaly
The connection to the share stays on, other files can be opened.
30 users problem occurs randomly, outlook 2002, exchange 5.5, PST on W2K3 file server running Norton AV 9

 

[CSCKone]

We moved 2nd 2003 server we had the problem with to another blade chassis and experienced the same problem.

We then moved 2 test users to a Win2K server in the same blade chassis, and the problem seems to have disappeared.

So there is something oddball about 2003 and how it interacts with something in the desktop load or possibly with PSTs in general. Since MS won't support PSTs over a LAN or WAN, I'm not sure where else to turn.

I hate having to move back to Windows 2000 for our home directories.

 

[WANguy2k]

Did you try turning off autodisconnect on the 2003 server? Is your Outlook set up using a mapped drive to their pst file? Is it possible the server is disconnecting the mapped drive?

net server config /autodisconnect:-1

Just a suggestion, not really sure if it applies.