<Feb 13 Edit appended to end of post>
Just to prove that knowledge of the past doesn’t replace proper planning, I got caught in the Schema update because while my Domain was operating at Windows 2003 functional level, my forest was not. The online documentation provides a link, here is where I ultimately landed if you have not performed this step before – <link>.
During the create pool phase I created 5 shares on my R2 server for the following purposes
- meeting content
- meeting metadata
- address book service
- application data
- client update data
The setup routine failed for me here with an Access Denied (permissions) for the file shares. The odd part is that the permissions were added to each shared and confirmed via the permissions table in the help file. I confirmed the r2pool HOST record exists in DNS and I also shortened the share clientupdatedata to clientupdate, this didn’t help. I am choosing to run setup from the SQL server as a test for 2 reasons – in the past I did this to avoid installing SQL client tools on my Front End servers and second the documentation offers this suggestion. This step did not work so I will use the option of /force as noted in the deployment information. Ok /force didn’t work either.
Guess what the problem was – sure the first thing you thought and the first thing anyone should think – permissions. I am not entirely sure of why but the only account in the RTCUniversalServerAdmins group was an account called SPAdmin (I will make a guess this is from the Update Service testing with 2007), so I added the Administrator account and rebooted all my virtual machines (reboot was over the top, logoff and logon should have been sufficient).
So the lessons I learned here – the default administrator account is ALL powerful, trust the error and investigate both the share security and account permissions, and lastly use the description field so you know why accounts like SPAdmin exist.
<Feb 13 Edit>
I would like to thank Jun Kong ??; Technical Account Manager ?????? for following up with me internally about issues with his Windows 2008 server permissions for the data files, I was deploying with Windows 2003 R2 and had not encountered the problem.
I’ve found out the reason.
In Windows 2008, we have 2 ways to share a folder:
1, Right click a folder and select “share…”. Then add permission for “Everyone”.
2, Right click a folder and select “Properties”. Then select “Sharing” ->”Advanced Sharing”. Then add permission for “administrator”.
The difference is about how to grant sharing permission. Yesterday, I use the second way to share OCS related folders. The default sharing permission is “Everyone Read Only”! That’s why I got “Access denied” error. Because administrator has no sharing permission of those folders…
Today, I removed the old pool and created a new one. At first time, I only gave “Everyone Read Only” SHARING PERMISSION to those folder and I got the “Access denied” error. Then I added “Administrator Full Control” SHARING PERMISSION to those folder and I created pool successfully.
BTW: yesterday, I recreated and shared folders in E: drive and use the first way to share them. I didn’t notice this difference. Now we know this error is not caused by Windows 2008 C: drive permission