Azure & Office 365

Topic details:

Today we will understand and troubleshoot more about SharePoint Service Application outside of SharePoint Central Admin. I came across multiple Forum issues who face service application issue but cannot troubleshoot it from IIS. Now this is an article which will help us understand more about issues and troubleshoot it.

 

Service Application and its properties in IIS:

Click Start > Run >Type “Inetmgr” > click ok > It will open the IIS screenshot for you.

Expand server you will see:

Application Pool : Application pools allow you to isolate your applications from one another, even if they are running on the same server. This way, if there is an error in one app, it won’t take down other applications. Additionally, applications pools allow you to separate different apps which require different levels of security.

Sites:  These are Virtual Directory which actually hosts the HTML, ASPX, etc files which will be accessed by users.

Lot of times users see some error message in ULS logs which refer to a service URL which is either timed out or some wired issue. Let check more about the URL’s we seen in those ULS Logs.

When you expand Site > “SharePoint Web Services”, you will see number of Virtual Directories. These are service applications connection used by SharePoint

Now let us check which GUID belong to which Service Application. To do so we will click on each GUID and select Content view on bottom page. Here we see GUID “4ae5be2ba3ad4452826c338528a0aca3” is hosting Search Admin service.

Similarly we can see GUID “c9f7fec2839a4e5c8056d4f30e00b8ea” host App management service and “ef2a78b8e67747e9aaeb708ae0230e5e” host WorkManagementService and so on.

 

 

We can check the Application Pool used by these services. To do so let’s right click on GUID > Manage Application > Advance Settings

Here we can see the Application Pool used by GUID and physical path of the service files.

We can Browse the service by clicking on any .svc file > select browse. This help us to understand if the service is working fine.

If we get a screen with below metadata, it means it is working fine. If we see any error on any of them, then we need to troubleshoot that issue.

To check Application Pool datails of the website we will go to Application pool screen and select the Application Pool > Right click > Select Advance settings. You would notice the .net framework version, identity (account used by application pool) and other IIS setting of that application pool

Incase if the Application pool is stopped we need to start it. Application pool may stop due to password change of account used in identity, IISReset, etc

 

 

Some Basic troubleshooting steps:

1. Create DisableLoopbackCheck registry on all SharePoint servers.

• Click Start, click Run, type regedit, and then click OK.
• In Registry Editor, locate and then click the following registry key:
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
• Right-click Lsa, point to New, and then click DWORD Value.
• Type DisableLoopbackCheck, and then press ENTER.
• Right-click DisableLoopbackCheck, and then click Modify.
• In the Value data box, type 1, and then click OK.

 

2. Sometimes some Application pool properties are edited. One of them is support for 32 but application. Make sure it is always set to False for all SharePoint Application pool. You need to go to IIS Manager > Application Pool > Select Application Pool > Advanced Settings > set “Enable 32-bit applications” to “False”.

3. If password used in Application pool account is changed, you may go to IIS Manager > Application Pool > Select Application Pool > Identity > Click on … near Application Pool username > Update the password for the application pool

4. Make sure Application pool account is present in WSS_WPG and WSS_ADMIN_WPG

5. I see a lot of time that IIS Hardening done by Windows admin cause this issue. Make sure that if you get an error e.g. 401, enable advance logging and check the exact error code like 401.1, 401.2, etc. This will help you troubleshoot issue. In below screenshot you can see all of them have a different reasoning.

 

6. Last but not least enable IIS logging. Logging specific details from IIS is the most important step

Select the web application > Select “Failed Request Tracing” on right pane >Enable the tracing.

Just by enabling you will not see the log files, now you will have to configure Error code. Again select Web Application > Select “Failed request tracing rules” > Select Add >Select All content > In Status code type 401(If you have something else you can put that) > Next > Finish. Now you will be able to see all failed request.

 

1. I some cases I have seen that due to antivirus or some other reason Application Pool account does not have permission on C:\InetPub folder. Make sure we have proper permission on Inetpub folder for service account and Application pool account.

During SharePoint Solution deployment or if we make any changes to IIS setting, it will generate a new web.config file. If we get some web.config errors, use tools like examdiff to check difference between old web.config and new web.config. This will help you narrow down issue track changes done in web.config. It is not recommended to modify any web.config unless necessary. Web.config should be in C:\inetpub\wwwroot\wss\VirtualDirectories\IIS site\ folder

Hope this was helpful to you all.

Comments are closed.