The other day I was working at a client’s site on their SharePoint Server 2010. I was creating and configuring service applications for their SharePoint environment when I ran into an interesting issue that I thought I will share with you.
At one point while I was creating a service, due to a typo the service wasn’t created but the application pool that I specified in the configuration got created. I know it was created because I could select it in the drop-down box in SharePoint when I tried to create the service application again. However, when I went to IIS 7 to delete the application pool it was not there. That was pretty confusing. At one point I deleted an existing service application and then recreated it. I experienced the exact same situation. The application pools were visible in SharePoint and not in IIS 7. I knew unless they are available in IIS 7 where you can manage them, they don’t really exist. I had to find a way to clean up the mess and get rid of the orphaned service application pools, especially because I wanted to use those names. After a little research I found the solution. Here’s how you can get rid of an orphaned application pool.
1. Start Windows PowerShell ISE located in Start, All Programs, Accessories, Windows PowerShell folder.. You can also use SharePoint 2010 Management Shell but I prefer to use Windows PowerShell ISE. You may have to install Windows PowerShell ISE if you haven’t already.
Best Practice: Use the Windows PowerShell ISE, which is 64-bit, instead of the 32-bit version called Windows PowerShell ISE (x86).
2. To view all the existing application pools type the following command and press enter.
Get-SPServiceApplicationPool | select Id, Name
You will notice that the left column lists the Ids and the right column lists the names. Here’s an example.
PS C:\Users\SP_Admin> Get-SPServiceApplicationPool | select Id, Name
4a3524ac-fb36-4b76-ab66-e8b4abca1cfc1 SeattlePro Search Service
cba42cbe-bb43-3524-8478-ae24826f904b SharePoint Web Services System
3. To delete the orphaned application pool type:
Remove-SPServiceApplicationPool -Identity “Name of Orphaned Application Pool”
What’s confusing here is that even though the command uses the switch called Identity, you don’t want to use the “Id”, you want to use the name of the application pool in the above command. For example, if the SeattlePro Search Service was the orphaned application pool that is available for you to use in SharePoint but you don’t see it in IIS 7, you will use the following command to delete it.
Remove-SPServiceApplicationPool -Identity “SeattlePro Search Service“
This should get rid of the orphaned application pool and you can recreate the pool by using the old name if you want.
Today I was installing Exchange Server 2010 Enterprise on a Windows Server 2008 R2 Domain Controller. Although Microsoft recommends that you install Exchange 2010 on a member server if possible, the environment I was working was very small so the Exchange Server 2010 was installed on a Domain Controller. There was an Exchange Server 2007 already in the same forest.
After I installed Exchange Server 2007 SP3 (at least SP2 was required in my scenario) to meet the prerequisites, I was unable to install Exchange Server 2010. During the installation I received the following error, indicating IIS was not installed on the Windows Server 2008 R2 server.
I installed IIS but still received the same error. The event viewer displayed the following warning:
Log Name: System
Date: 7/10/2010 8:54:01 AM
Event ID: 5153
Task Category: None
Description: The Windows Process Activation Service (WAS) encountered an error attempting to look up the built in IIS_IUSRS group. There may be problems in viewing and setting security permissions with the IIS_IUSRS group. This happens if the machine has been joined and promoted to be a Domain Controller in a legacy domain. Please see the online help for more information and solutions to this problem. The data field contains the error number.
Upon further investigation, I discovered that according to Microsoft KB article 946139, this is by design. Translation: This is a FEATURE, not a BUG.
You have a Windows Server 2008-based server that is running Internet Information Services (IIS) 7.0. You set the Windows Server 2008-based server as a domain controller of a Windows 2000-based domain or of a Windows Server 2003-based domain. In this scenario, you cannot resolve the built-in IIS accounts, such as the IIS_IUSRS group or the IUSR guest user account. You can see only the raw security identifier (SID) of the built-in IIS accounts.
Note: This problem does not occur if you set the Windows Server 2008-based server as a domain controller of a Windows Server 2008-based domain.
This problem occurs because the IIS 7.0 built-in accounts specification for Windows Server 2008 does not exist in earlier domains, such as Windows 2000-based domains and Windows Server 2003-based domains. When the IIS 7.0 server is set as a Windows 2000-based domain controller or a Windows Server 2003-based domain controller, the Windows Server 2008 accounts cannot be resolved.
This TechNet article explains Event ID 5153 in more detail. Essentially, you have to remap the built-in IIS accounts. IIS 7.0 uses several built-in Windows Server 2008 accounts, including the IIS_IUSRS group and the IUSR guest user account. These replace the <MACHINE_NAME>_USR account that was created by IIS 6.0.
A problem occurs when a Windows Server 2008 computer that hosts IIS 7.0 becomes a domain controller (DC) of a non-Windows Server 2008 domain (that is, a DC of a Windows 2000 or Windows Server 2003 domain). When the DC promotion occurs, the new Windows Server 2008 built-in accounts are no longer available to IIS 7.0. Any Access Control List (ACL) that uses the built-in accounts will not be able to resolve to a friendly name, but will instead show their raw SID (Security Identifier) values.
To resolve this issue, run a script that will restore the mapping of SIDs to friendly names for the built-in accounts. The script must be run on the DC while it is connected to its Primary Domain Controller (PDC). This will reestablish access to the built-in accounts that IIS 7.0 requires.
To resolve this problem, use this sample script. Save it as SamUpgradeTask.js.
Note: You must restart the server after you run this script.
After you have taken all these steps you may still get the same error, at least I did, and I know others have been in the same boat. Try these additional steps.
1. Go to Server Manager/Web Server (IIS)/Add role services and check the box for IIS 6 Management Compatibility. If that doesn’t help then go to step 2.
2. Start the PowerShell with elevated privileges (Start, All Programs, Accessories, Windows PowerShell) and run the following scripts one-by-one. You must start the PowerShell with elevated privileges, i.e. Run as Administrator.
- Import-Module ServerManager
- Add-WindowsFeature NET-Framework,RSAT-ADDS,Web-Server,Web-Basic-Auth,Web-Windows-Auth,Web-Metabase,Web-Net-Ext,Web-Lgcy-Mgmt-Console,WAS-Process-Model,RSAT-Web-Server,Web-ISAPI-Ext,Web-Digest-Auth,Web-Dyn-Compression,NET-HTTP-Activation,RPC-Over-HTTP-Proxy -Restart
- Set-Service NetTcpPortSharing -StartupType Automatic
Notice that after the second script your server will reboot. You may run the third script manually or use the GUI by going to the Services Console (services.msc) and set the Net.TCP Port Sharing Service to start automatically. Restart the Exchange Server 2010 setup again and Exchange should install successfully this time.
Have you ever received a warning message when installing SQL Server 2005 that indicates that you do not have Internet Information Services (IIS) installed, even though you have and it is working perfectly fine? I ran into a similar situation when I was installing SQL Server 2005 Enterprise x64 on a Windows Server 2008 R2 Enterprise x64 edition. Here’s what the warning message looked like. Notice that the warning is related to the IIS Feature Requirement and ASP.NET Version Registration Requirement.
If you don’t have all the components required by SQL Server 2005 on the server, you will get the above warning message. There are a couple of IIS 6 compatibility components that must be installed, such as IIS Metabase Compatibility and IIS 6 WMI Compatibility. These are both listed in the section IIS 6 Management Compatibility that’s located under Mangement Tools section. You can install these components by going to Roles, Add Role Services in the Server Management console in Windows Server 2008.
You may also have to start the ASP.NET State Service. You can verify that all the required services have started in the Server Manager console by clicking on Web Server (IIS) under Roles. Look in the System Services section to verify that all required services have started. If not, go to Services console (Start, Run, services.msc) and start the services.
This KB article describes the issues in more detail. Although, the KB article mentions the Server Core edition of Windows Server 2008, you may experience this issue on other versions of Windows Server 2008 as well. In my case I was using Windows Server 2008 R2 Enterprise x64.
After you add the two services that I’ve mentioned above, the installation should continue smoothly and you should see the following screen indicating success for all the installed features.
Don’t forget to install the latest Service Pack for SQL Server 2005 before using the SQL Server. At the time of writing, SP3 was the latest version.
Missing SQL Server Management Studio
While configuring SQL Server, another issue that you may run into is that you may not find the SQL Server Management Studio after the installation. Whether it’s the lack of knowledge (I admit I am not a SQL Server expert) or poor design and documentation on part of Microsoft, this has been a source for confusion and frustation for lots of people all over the world. Different techniques work for different folks. Check out Pete Orologas’ blog for various solutions. I ran SqlRun_Tools.msi from the source CD (Tools\Setup folder) and installed the SQL Management Studio. When you double-click the file to run the executable, the SQL Management Studio is located under Client Components, Magement Tools. I also installed the Connectivity Components and all the features listed under Documentation, Samples, and Sample Databases.
Hopefully these tips will help you get your SQL Server 2005 up and running with all the necessary features included.
When working with MOSS 2007, especially on Windows Server 2008 (WS08), some administrators find it difficult to locate the option to enable Anonymous Authentication. Enabling Anonymous Access is not very intuitive in MOSS 2007 and requires you to go through several hoops. In a previous blog The Challenging Task of Managing SharePoint Permissions, I discussed how challenging it is to manage permissions in SharePoint (don’t forget to read my prediction in that blog post). Frankly, the entire design of permission management is a huge mess. People are so used to finding workarounds and waiting for the patches to be released to fix the holes, and then other patches to fix the updates that caused the mess in the first place, that they have pretty much stopped complaining. The complicated and confusing design for enabling Anonymous Access is just one example of the overall deficiency in SharePoint to better manage permissions and secure SharePoint sites.
If you go to the Site Settings, Advanced Permissions and do not see the Anonymous Access option in the Settings drop-down menu then your site is not configured for Anonymous Access. Enabling Anonymous Access is a three-step process. Here’s how you can enable Anonymous Access for a MOSS 2007 site.
Step 1: Enable Anonymous Authentication in IIS
1. First, make sure that you have enabled Anonymous Authentication in Internet Information Services (IIS). For IIS 6.0 (WS08) and IIS 6.1 (WS08 R2), start the IIS Manager and expand the Sites folder.
2. Click your Web site.
3. In the right hand pane double-click Authentication in the IIS section.
4. Right-click Anonymous Authentication and click Enable.
You need to take a couple of additional steps before Anonymous Authentication will work for your SharePoint site.
Step 2: Enable Anonymous Access in SharePoint Web Application
1. Start Central Administration using an account that has Site Collection Administrator privileges.
2. Click on the Application Management tab.
3. In the Application Security section click “Authentication providers.”
4. Select the Web Application for which you want to enable Anonymous Access.
5. Click the Default zone.
6. In the Anonymous Access section, check the box “Enable anonymous access” and then click Save.
7. Go to the Site Settings, Advanced Permissions and verify that the Anonymous Access is available from the Settings drop-down menu.
Wait! You are not done yet. So far you’ve enabled Anonymous Access in IIS and Web Application. You still need to perform a third step.
Step 3: Enable Anonymous Access for the Web Site
1. Go to your Web site’s Site Permissions page (Site Settings, Advanced Permissions).
2. From the Settings drop-down menu click Anonymous Access.
3. Check the radio button “Entire Web site” and click OK.
At this point you have completed all the steps necessary to enable Anonymous Access for your Web site. Test to make sure that Anonymous users can access the site.
There is one thing that will drive you crazy if you are new to MOSS 2007. Even after you configure the permissions and restrict a library or a list from Anonymous users, you may notice that the Anonymous users still have access to the library or list. You can work around this issue by going to the Settings menu while inside the library and then click Anonymous Access. Uncheck the box View Items.
If you are having issues with Anonymous Access, you might also be interested in reading my blog post How to Configure Survey Lists for Anonymous Access in which I discuss the solutions for some other undocumented “features” in SharePoint.
A lot of people, especially those who are relatively new to managing and editing Web sites, use Microsoft FrontPage. More experienced people prefer other tools, such as Dreamweaver or Microsoft SharePoint Designer, or even Expression Web because they do a much better job of editing HTML pages than FrontPage. This blog post is for those individuals or Internet Service Providers (ISPs) who are using FrontPage Server Extensions (FPSE).
Once you’ve upgraded your Windows Server 2003 to Windows Server 2008 (WS08) you may realize that the IIS 7.0 in WS08 no longer supports FrontPage Server Extensions (FPSE). Same is true for IIS 7.0 in Windows Vista. Because there are tons of Web hosting providers who rely on FPSE, Microsoft and Ready-to-Run Software offer a special version of FPSE. This new version is called FPSE 2002 and will work on IIS 7.0 running on 32-bit and 64-bit versions of Windows Vista and WS08 computers. You can download FPSE 2002 here.
To install FPSE on your WS08 server, login as an administrator account, or start the command prompt using “Run As Administrator” and type the following command.
msiexec /i <path to FPSE 2002 file>\fpse02_win2008_vista_rtm_ENG.msi
Installing FPSE 2002 on WS08 requires that you install several additional services and features. If you don’t want these services installed then you can’t install FPSE 2002. These include the following:
Web Server (IIS) Role Services
- Common HTTP Features (Static Content, Default Document, Directory Browsing, HTTP Errors)
- Application Development (ISAPI Extensions, ISAPI Filters)
- Security (Windows Authentication, Request Filtering)
- Health and Diagnostics (HTTP Logging, Request Monitor)
- Performance (Static Content Compression)
Management Tools (Role Services)
- IIS 6 Management Compatibility (IIS 6 Metabase Compatibility)
- IIS Management Console
Windows Process Activation Service
- Process Model
I should point out that Microsoft’s FrontPage Server Extensions have a history of known issues so be very careful. Backup your server before installing FPSE 2002. Make sure you read the note at the end of installation, as shown below.
Copyright © 2013 Zubair Alexander. All rights reserved.
25 queries. 0.740 seconds