The other day I had a support case where temporary outage of AD DS infrastructure caused K2 workspace to enter into the error state where it started throwing the following error:
“An error has occurred.
Please contact your administrator.
Error:
Initialization failed before PreInit: Unable to establish a secure connection with the Active Directory server.
Possible causes
– the ADConnectionString in the K2 Workspace web.config may have an incorrect LDAP path.
– the physical connection to the Active Directory Server might be down.
– please review log files for more information.”
Just for lazy readers and those in a hurry: Bump into error above? Try Recycle Application Pool which runs your K2 Workspace (default application pool name is “K2”).
The tricky thing here that it is really easy to miss short period of AD outage and start “fixing” K2 instead. But in case this is an environment which used to work and you are sure that no changes were made in K2 configuration recently then it is just an issue caused by AD DS outage.
When K2 Workspace is loaded it attempts to establish the connection with AD as the application pool account. If there is an issue with accessing AD under this account it leads to above mentioned error. What can be wrong with this account? It can be disabled or locked out in AD but also after AD DS outage it may be necessary to perform K2 workspace application pool restart to force it to reconnect to AD DS. Now the interesting thing here is that a lot of people trying to use a big hammer immediately, i.e. iisreset and it may not fix this issue sometimes (according to my experience) leaving you wondering why IIS reset does not fix this, where as just K2 Workspace application pool restart does.
In attempt to remove any confusion you mat want to read up a bit on iisreset VS Recycling – and good explanation of this can be found here. Your main take away from that post should be understanding of IIS architecture and its 3 main components:
Image source – IIS7 For Non IIS PFEs
Three components are the following:
- HTTP.SYS (runs in Kernel Mode). This component responsible for client connection management, routing requests from browsers, and managing response cache.
- Worker Processes (run in User Mode). If you look at the picture above that we may also have so called Web Garden which is nothing more than application pool which allowed to use more than one worker processes by means of setting “Maximum number of worker processes” to a value higher than 1. Web garden feature has been designed for one purpose which is “Offering applications that are not CPU-bound but execute long running requests the ability to scale and not use up all threads available in the worker process.” Leaving out Web Gardens each Application Pool has one specific worker process within which it is running (W3wp.exe). Worker process handles all the contents (aka static contents), such as HTML/GIF/JPG files, and runs dynamic contents, such as ASP/ASP.NET applications. Therefore, the status of W3WP process (=Application Pool) is critical for the performance and stability of web applications, or web sites.
- IIS Admin Services (run in User Mode). Prior to IIS7 there used to be IISADMIN service which used to host the IIS 6.0 configuration compatibility component (metabase). The metabase is required to run IIS 6.0 administrative scripts, SMTP, and FTP. Starting from IIS7 we have Windows Process Activation Service (WAS) which manages application pool configuration and worker processes instead of the WWW Service. This enables you to use the same configuration and process model for HTTP and non-HTTP sites.
OK it seems I went in too much of details here and now have to get back to main topic here: main thing for you to know is what actually happens when you execute iisreset. It actually restart IIS services (all of them) and for most of us this is exactly what we expect and this is what may make you wonder about why IIS reset does not fix an issue, where specific application pool restart does it? Sounds strange…
I would venture to suggest that iisreset may fail to restart some of specific w3wp processes sometimes but after spending couple of hours searching through the web and doing couple of quick tests this does not seem to be the case. But what I can say based on above mentioned article you should actually prefer Application Pool recycle anyway.
On a side note I would also be aware of the following iisreset keys:
iisreset /status
Output of this will look as follows:
It gives you current status of all IIS services as well as what exactly will be restarted by iisreset.
iisreset /noforce
This parameter prevents the server from forcefully stop worker processes process. This can cause IIS to reset slower but is more graceful. With this parameter it is a compromise between lowering downtime and trying to be less disruptive to what is already running.
And just to confirm iisereset executed without any keys is the same iisreset /restart
Getting back to K2 Workspace issue mentined in the very beginning of this article my advice is try to Recycle your K2 workspace application pool – it is preferable and less disruptive action than iisreset. When you recycle an application pool, IIS will create a new process (keeping the old one) to serve requests. Then it tries to move all requests on the new process. This is known as “overlapped recycling” as opposed to “process recycling” and it is default behavior for all IIS application pools.
In case it did not help you to resolve “Initialization failed before PreInit: Unable to establish a secure connection with the Active Directory server” error in K2 Workspace below are some K2 side checks to do. Make sure that:
- K2 Workspace site is running in IIS Manager (not Stopped)
- Application Pool designated to run this site and applications therein are running as well. If they are not running, the service account running the K2 Workspace application pool may be locked in Active Directory.
- Make sure the Workspace Application Pool account has at least read access in AD for the newly added domain (in case you added any) or in one which you always had. When Workspace is loaded it attempts to establish the connection with AD as an application pool account.
- Try including the domain controller name and LDAP port number in the LDAP connection string as follows:
<add name="ADConnectionString2" connectionString="LDAP://[DomainControllerName]:[port]/MyDomain.com" />
OR
<add name="ADConnectionString2" connectionString="LDAP://[DomainControllerName]/MyDomain.com" />
- If you continue to get the same error you may try using the Distinguished name format for the domain instead, for example:
<add name="ADConnectionString2" connectionString="LDAP://[DomainControllerName]/DC=MyDomain,DC=com" />
If after checking all these things issue still persist consider enabling TracingPath in the Workspace web.config, to get a more detailed debug output from the PreInit error.