The guidance around where to create your pool and why can be quite confusing.
If you look at the OCS R1 requirements for deploying an Enterprise Pool, it tells you the following:
- If you are using a 32-bit version of SQL Server, log on to your Office Communications Server Back-end Database server as a member of the Domain Admins group.
- If you are using a 64-bit version of SQL Server, create the pool by using a computer with a 32-bit processor, such as the computer that you plan to use as the Front End Server. Log on to the 32-bit processor computer as a member of RTCUniversalServerAdmins and Domain Admins group and with user rights to create and modify SQL Server databases.
If you look at the OCS R2 requirements for deploying an Enterprise Pool, it tells you the following:
- If you are using a 64-bit version of SQL Server, log on to your Office Communications Server Back-end Database as a member of RTCUniversalServerAdmins and DomainAdmins group.
- If you are using a 32-bit version of SQL Server, create the pool by using the computer that you plan to use as the Front End Server. Log on to this computer as a member of RTCUniversalServerAdmins and Domain Admins group and with user rights to create and modify SQL Server databases.
As you can see, it’s a complete 180 between R1 and R2. To make it easier to digest, here’s an easier format to see what you should do:
OCS R1 with SQL 32-bit – Create Pool on SQL
OCS R1 with SQL 64-bit – Create pool on OCS FE
OCS R2 with SQL 32-bit – Create Pool on OCS FE
OCS R2 with SQL 64-bit – Create Pool on SQL
The reason why it’s a complete 180 is because Microsoft wants you to run the installer on the native platform of the installer. OCS R1 is 32-bit so you always want to run the installer on a 32-bit machine. OCS R2 is 64-bit so you always want to run the installer on a 64-bit machine.
But the million dollar question is, is it really necessary to run it from the Backend? Does that mean you have to insert your OCS CD, install .Net Framework, Visual C++, etc…. Well, you could, but you can use LCSCMD to configure your pool instead. LCSCMD is on your CD and you can just open a cmd prompt, navigate to your cd-rom, and run the LCSCMD command with the appropriate settings to configure your pool without needing to install at the tools the installer GUI would require. LCSCMD would also bypass the requirement from running the installer on the same processor platform (x86/x64.) You can refer to the following article here for information on how to use LCSCMD to create an Enterprise Pool.
But, that doesn’t really explain why it is recommended running it on the Backend. After talking with Ken Alverson from Microsoft about this, I learned a few things. The reason they recommend to create the pool on the SQL Server is to minimize the possibility of firewall/permissions from interfering. The Create Pool requires access to both SQL as well as WMI. You can technically open up all the ports to SQL as well as WMI and run Configure Your Pool from your OCS Server. This is what I did but instead of opening it completely, I ran Network Monitor to determine what ports to open. You could also disable your Windows Firewall on your SQL Server to ensure access to your SQL Server. Never disable the firewall service on Server 2008 as this disrupts proper communication. Either turn the firewall off or go into the advanced firewall in the administrative tools and open everything up.
So in short, you have the following options with OCS R2:
- Turn off firewall on SQL (don’t disable firewall service) and install from OCS Server (lowers security but easiest to do.) After the pool is created, you can re-enable your firewall as long as you follow the OCS documentation (installation guide for Enterprise Edition) and open the necessary ports.)
- Allow SQL Ports and WMI to traverse SQL Firewall (more secure than #1 but less easy to do)
- Run Create Pool from SQL Server via the GUI Installer (more secure than #1 and #2 but not an option I like due to it installing GUI prerequisites)
- Run Create Pool from LCSCMD via the CD which will install a SQL prerequisite I believe (most secure option but requires knowledge of the LCSCMD command.) You can refer to the following article here for information on how to use LCSCMD to create an Enterprise Pool.
I would appreciate if readers can make a quick comment on what method you use.
Personally, I'd go with something I'm a little more familiar with. SQL gets my vote here, even if I do need sql server support from time to time.
this is great post and i learn a lot knowledge from this post and i will concerning it agian and hope you come to our online store to choose any you need the product!
Looking for an advanced amateur photo club – Ive reasearched online and found one in Palo Alto and San Rafael, each location about an hour or so away from me….anyone know of any in say, San Francisco or the East Bay? If not, anyone interested in joining one?
I am still having issues creating the pool. Installing it directly on the server. I am using OS of Server 2008 Standard and SQL 2008 Standard. Have fully elevated permisssions in both sql, domain and the local server. Anything else I should look for?
Na, it’s correct. Look at the other documentation above that which is straight from OCS documentation. For example, for R1:
* If you are using a 32-bit version of SQL Server, log on to your Office Communications Server Back-end Database server as a member of the Domain Admins group.
* If you are using a 64-bit version of SQL Server, create the pool by using a computer with a 32-bit processor, such as the computer that you plan to use as the Front End Server. Log on to the 32-bit processor computer as a member of RTCUniversalServerAdmins and Domain Admins group and with user rights to create and modify SQL Server databases.
Microsoft will always prefer you to create the database on SQL to minimize the potential issue I discussed. The documentation above is not a “you have to” but more of a recommendation to minimize potential issues. Sure, you can still create the database wherever you want if firewall is disabled, ports are open, etc. as I mentioned in my article.
So taking a look at R1, since SQL is 32-bit, they want you to create the database on SQL Pool because it’s preferred to create database on SQL and if you use the GUI, it should be done from the same CPU Architecture.
So what I wrote is correct. :)
I think you put this part a bit backwards
OCS R1 with SQL 32-bit – Create Pool on SQL
OCS R1 with SQL 64-bit – Create pool on OCS FE
OCS R2 with SQL 32-bit – Create Pool on OCS FE
OCS R2 with SQL 64-bit – Create Pool on SQL (R2 is 64 bit so shouldn’t the OCS FE create the pool as said in the test above this section)
shouldn’t it be
OCS R1 with SQL 32-bit – Create pool on OCS FE
OCS R1 with SQL 64-bit – Create Pool on SQL
OCS R2 with SQL 32-bit – Create Pool on SQL
OCS R2 with SQL 64-bit – Create Pool on OCS FE
the way we did it was pretty much straight forward (as its just OCS 2007 R2 Std)
run the installer and let the FE create the pool (even though its a bit anoying that SQL2005 isn’t native 64 but Std can’t have 2008 forced on it)
In my labs, I have always done OCS to SQL and just shut off the firewall. In production, before I knew the different scenarios, we ended up installing on the SQL as that was the Microsoft recommendation and we didn’t really think about LCSCMD.
Now that I know about this, I’d either shut off the firewall on SQL (at least temporarily till the pool is created and then re-enable it) and then create the pool from the OCS Server or just use LCSCMD.
Elan,
I always like to create the pool from the pool server. Just make sure that the proper SQL tools are installed on the pool server. The SQL tools are on disk 2 of sql 2005 sp2 distribution. Ditto for SQL 2008.
My reasoning, however flawed, is that if I can accomplish this from the pool server, then I should have no SQL-OCS communication errors.
John