Installing Bitrix24 on IIS server using MSSQL and AD
The other day, the challenge was to test this corporate portal in the boxed version. Having spent a lot of time and effort, I decided to describe this process in order to save someone extra efforts.
Let's start with the fact that in my organization I have a “ecosystem” of software built on the basis of Windows systems and there are a large number of application applications written for our tasks and it was required to use MSSQL to integrate them. Therefore, it was decided to allocate a Windows Server virtual machine for product testing.
After reading the proposed solutions, I decided to try three options:
1. Installing the portal on your IIS server with PHP and MSSQL
')
The first item failed at the beginning: having passed all the configuration steps according to instructions from the developers, half of the functions did not work in the installed portal. As analysis and appeal to technical support showed, the problem was in redefining URLs. As I was told, a successful launch under IIS has not yet worked. Decided to check further.
2. Installing the proposed kit with a web environment (Apache with PHP, mysql and XMPP).
Installing the “default” kit started immediately, but with some problems. The speed of work was rather low, attempts to adjust the cache and compression did not help much. Switching to HTTPS did not work, despite the separately derived settings in the console. Apparently it was not for nothing that on the official website there was a postscript “The Bitrix: Web Environment Package” is recommended to be used only for testing trial versions. BitrixVM is recommended for the real project to work.
3. Virtual machine Bitrix with cent-os.
Some modes did not work when choosing an installation. I went only to install the demo version. There was no choice of database to use. The system has not been installed support MSSQL.
I had to go back to the first option. Having tortured what is on this on the Internet, I found out that the rules for URL redefinition are written in the .htaccess file and IIS does not understand it. I decided to convert the .htaccess rules into a server-friendly form by getting the following section for the web.config file:
All the missing functions seem to have earned, and we could have been happy, but having entered the account from the Active Directory, the chat fell off. Having sinned on IIS, I shoveled all the settings, but nothing helped. And only by experience was the reason found:
The portal configuration wizard incorrectly creates user groups and does not have access to the chat, and sometimes to the main page.
To fix this problem, it was enough to replace the groups to which the user is added after logging in from AD
In the right highlighted part, it is enough to replace the groups with the prefix “SITE_WIZARD:” with similar groups without this prefix.
After installing the cache for PHP, performance also tightened to an acceptable level. For me, it remains to solve only the problems of non-working auto-update and docking of the mail domain via IMAP, but these are already technical support questions that have not been answered yet. And after, you can solve the issue of acquisition. Although some sediment, of course, there remained a flaw in the installation of the product.
I hope this will help someone)
Let's start with the fact that in my organization I have a “ecosystem” of software built on the basis of Windows systems and there are a large number of application applications written for our tasks and it was required to use MSSQL to integrate them. Therefore, it was decided to allocate a Windows Server virtual machine for product testing.
After reading the proposed solutions, I decided to try three options:
1. Installing the portal on your IIS server with PHP and MSSQL
')
The first item failed at the beginning: having passed all the configuration steps according to instructions from the developers, half of the functions did not work in the installed portal. As analysis and appeal to technical support showed, the problem was in redefining URLs. As I was told, a successful launch under IIS has not yet worked. Decided to check further.
2. Installing the proposed kit with a web environment (Apache with PHP, mysql and XMPP).
Installing the “default” kit started immediately, but with some problems. The speed of work was rather low, attempts to adjust the cache and compression did not help much. Switching to HTTPS did not work, despite the separately derived settings in the console. Apparently it was not for nothing that on the official website there was a postscript “The Bitrix: Web Environment Package” is recommended to be used only for testing trial versions. BitrixVM is recommended for the real project to work.
3. Virtual machine Bitrix with cent-os.
Some modes did not work when choosing an installation. I went only to install the demo version. There was no choice of database to use. The system has not been installed support MSSQL.
I had to go back to the first option. Having tortured what is on this on the Internet, I found out that the rules for URL redefinition are written in the .htaccess file and IIS does not understand it. I decided to convert the .htaccess rules into a server-friendly form by getting the following section for the web.config file:
<rewrite> <rules> <rule name="bitrix rewrite URL" stopProcessing="true"> <match url="^(.*)$" ignoreCase="false" /> <conditions logicalGrouping="MatchAll"> <add input="{REQUEST_FILENAME}" matchType="IsFile" ignoreCase="false" negate="true" /> <add input="{REQUEST_FILENAME}" matchType="IsDirectory" ignoreCase="false" negate="true" /> <add input="{REQUEST_FILENAME}" pattern="/bitrix/urlrewrite.php$" ignoreCase="false" negate="true" /> </conditions> <action type="Rewrite" url="/bitrix/urlrewrite.php" /> </rule> </rules> </rewrite> All the missing functions seem to have earned, and we could have been happy, but having entered the account from the Active Directory, the chat fell off. Having sinned on IIS, I shoveled all the settings, but nothing helped. And only by experience was the reason found:
The portal configuration wizard incorrectly creates user groups and does not have access to the chat, and sometimes to the main page.
To fix this problem, it was enough to replace the groups to which the user is added after logging in from AD
In the right highlighted part, it is enough to replace the groups with the prefix “SITE_WIZARD:” with similar groups without this prefix.
After installing the cache for PHP, performance also tightened to an acceptable level. For me, it remains to solve only the problems of non-working auto-update and docking of the mail domain via IMAP, but these are already technical support questions that have not been answered yet. And after, you can solve the issue of acquisition. Although some sediment, of course, there remained a flaw in the installation of the product.
I hope this will help someone)
Source: https://habr.com/ru/post/280402/
All Articles