npdodge
asked on
Cannot create public folders in Exchange 2013
I completed the public folder migration over the weekend from Exchange 2007 to 2013. I ran the scripts to compare public folder structure, permissions, etc. at the end and everything seemed ok. I even logged in and tested things like creating folders, deleting them, and adding items.
Now it's the start of the work week and users are in and out of public folders, adding content, etc. The issue we seem to be having is that it appears that we cannot create new public folders in Outlook. We get an error that just says "cannot create folder". The folder then appears in EAC but if you highlight it a yellow banner appears on the left saying "the process failed to get the correct properties". I will get this banner for public folders I try to create directly in EAC as well. Folder permissions are correct, and I'm owner of the public folder and parent folder. The only solution I've been able to find on the net is to put the Primary Hierarchy public folder in it's own database. Seems excessive especially when I'm running standard and would like to distribute all of my user mailboxes into four databases.
Our public folders are quite large. We have over 75,000 public folders and about 13 million email items. The database that has all of the public folder mailboxes is 134GB and there are 32 public folder mailboxes total. Right now I have 2 Exchange 2013 servers in a DAG locally and one DAG member off-site. All four databases with user mailboxes are on one server and the database with all the public folders is on the other local server. Each server has 40GB of RAM. The off-site DAG member has no active DBs and is just for DR purposes. Any suggestions?
Now it's the start of the work week and users are in and out of public folders, adding content, etc. The issue we seem to be having is that it appears that we cannot create new public folders in Outlook. We get an error that just says "cannot create folder". The folder then appears in EAC but if you highlight it a yellow banner appears on the left saying "the process failed to get the correct properties". I will get this banner for public folders I try to create directly in EAC as well. Folder permissions are correct, and I'm owner of the public folder and parent folder. The only solution I've been able to find on the net is to put the Primary Hierarchy public folder in it's own database. Seems excessive especially when I'm running standard and would like to distribute all of my user mailboxes into four databases.
Our public folders are quite large. We have over 75,000 public folders and about 13 million email items. The database that has all of the public folder mailboxes is 134GB and there are 32 public folder mailboxes total. Right now I have 2 Exchange 2013 servers in a DAG locally and one DAG member off-site. All four databases with user mailboxes are on one server and the database with all the public folders is on the other local server. Each server has 40GB of RAM. The off-site DAG member has no active DBs and is just for DR purposes. Any suggestions?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
I lnow that public folders dont habe to be in their own database, but I need them to have larger quotas than my mailbox users which why they are in their own database.
ASKER
https://technet.microsoft.com/en-us/library/jj906435(v=exchg.150).aspx
Do I just follow this article to simply move the public folders out of the primay hierarchy mailbox and into a new mailbox?
Do I just follow this article to simply move the public folders out of the primay hierarchy mailbox and into a new mailbox?
ASKER
Is the issue im having as the result of not having an empty primary hierarchy mailbox or because I have all the pf mailboxes in one database? The database is only 134GB right now.
You can apply quotas to a mailbox directly - you don't have to use the database level quota.
The size shouldn't matter, but it would be much easier to manage if you split the data up - whether that is just in to multiple databases or just multiple mailboxes on the same database.
Otherwise it is just a matter of creating a new Public Folder Mailbox then creating the move requests.
Simon.
The size shouldn't matter, but it would be much easier to manage if you split the data up - whether that is just in to multiple databases or just multiple mailboxes on the same database.
Otherwise it is just a matter of creating a new Public Folder Mailbox then creating the move requests.
Simon.
ASKER
Ok. But you feel the primary reason is not having an empty primary hierarchy. I will probably have to wait until after hours tonight to do this. The article says that users can access pfs during the move but I dont want it to affect exchange performance. I will give u an update later. Thanks
"But you feel the primary reason is not having an empty primary hierarchy."
No, not really.
I think the primary reason for the problems is simply that it is a migration. Putting the hierarchy in to its own empty mailbox appears to be becoming best practise, although there is no formal recommendation from Microsoft, other than the references you have already seen.
Simon.
No, not really.
I think the primary reason for the problems is simply that it is a migration. Putting the hierarchy in to its own empty mailbox appears to be becoming best practise, although there is no formal recommendation from Microsoft, other than the references you have already seen.
Simon.
ASKER
Does it end up clearing itself up? Today people are able to create folders and we havent done anything yet.
You will get replication within the domain which may correct some issues, particularly 48 hours after the initial migration (the replication time outs). If you think it is working correctly, then great, but I would still plan to split the data up, simply to make management much easier.
Simon.
Simon.
ASKER
Well, now we are getting reports again that users cannot create folders. Also, found out this morning that logs are not truncating on the database (with all the PF mailboxes) after a successful full backup. We initially had circular logging enabled on that database during the migration but disabled that after it went live. Not enjoying Exchange 2013 public folders so far. Any suggestions?
The fact that you are using public folders has nothing to do with the log issue - as public folders are now just another mailbox. The logs not flushing after a backup is classic sign of the DAG not replicating correctly.
Simon.
Simon.
ASKER
Yeah that was the case. We resolved that today. Sorry I didn't update you, it's been hectic here.
ASKER
I don't understand why its necessary to stagger the PF mailboxes across other databases. We are well under the size limit for the database and the PF mailboxes themselves are not that big. I've also noticed that when the database hosting all the PF mailboxes activates on the other server, it seems to hose up.
What would you recommend that I try first? Moving some PF mailboxes to other databases or moving content out of the primary hierarchy mailbox?
What would you recommend that I try first? Moving some PF mailboxes to other databases or moving content out of the primary hierarchy mailbox?
ASKER
I do want to thank you for assisting me. I've been reading your suggestions for years on EE and respect your recommendations Simon.
Two reasons for spreading them out.
1. It spreads the load.
2. If you have to restore a mailbox, you reduce the amount you need to restore.
You have a 135gb mailbox - that will take time to restore if you needed to.
However if you split it up, then it is quicker to restore.
Same if you needed to do any repair on the database.
It can also make it easier to manage - most public folders are accessed by a small number of people, so you can easily group them together. In the event of a problem you know who is impacted.
Simon.
1. It spreads the load.
2. If you have to restore a mailbox, you reduce the amount you need to restore.
You have a 135gb mailbox - that will take time to restore if you needed to.
However if you split it up, then it is quicker to restore.
Same if you needed to do any repair on the database.
It can also make it easier to manage - most public folders are accessed by a small number of people, so you can easily group them together. In the event of a problem you know who is impacted.
Simon.
ASKER
My whole company of 370 uses public folders. :) Almost all emails that are communicated to clients are stored in public folders. Should I consolidate my four databases that have user mailboxes into 3 and create a new database for public folder mailboxes? The other four are 117GB, 71GB, 72GB, and 60GB and they could grow too because most users haven't hit near their quota.
ASKER
I guess I should follow this document and move some content out of the primary hierarchy DB.
https://technet.microsoft.com/en-us/library/jj906435(v=exchg.150).aspx
https://technet.microsoft.com/en-us/library/jj906435(v=exchg.150).aspx
When it comes to database size, I usually work to a limit of around 250gb. Therefore you are well away from that.
If you have users accessing all of the folders then there might be some benefit from having all of the content in its own database. Whether that will give you any performance gains very much depends on the storage configuration.
What I meant by use of public folders is that you may have some public folders for "Sales" which are used by just the sales group, "Accounts" which is used by finance and "IT" which is used by the IT department, making it easy to group the folders together.
Simon.
If you have users accessing all of the folders then there might be some benefit from having all of the content in its own database. Whether that will give you any performance gains very much depends on the storage configuration.
What I meant by use of public folders is that you may have some public folders for "Sales" which are used by just the sales group, "Accounts" which is used by finance and "IT" which is used by the IT department, making it easy to group the folders together.
Simon.
ASKER
Yeah I kind of left the public folder to mailbox mapping as is when I ran that PS script during the pre-migration phase. All of the databases are on the same set of physical drives.
ASKER
Simon, things appear to be much better after having an empty primary mailbox.
ASKER