Sunday, May 19, 2013

Setting up Forms Based Authentication for Active Directory (SP2013/SP2010)

Setting up Forms Based Authentication for Active Directory

I've seen a number of posts on setting FBA for AD; most however leave out one or two details to actually get it to work - the following guide should assist you! Note that while this is based on 2010, it applies to 2013 as well.

BE FOREWARNED: There are very subtle differences between the web.config files so be very careful as you do this - also MAKE A BACKUP BEFORE YOU EDIT a web.config file (failing to do so will create a major headache if you have to reset to scratch!).

The setup of Forms Based Authentication (FBA) within SharePoint is based on the application setup using Claims Based Authentication and by making modifications of the web.config files on all front-end servers.

NOTE: While the setup of the application is done through the User Interface (Central Administration), changes to the web.config files can be done programmatically or more simply, editing the files. This can pose a challenge in some farm environments - SharePoint stores web.config settings within the database and depending on the circumstances, will ‘overwrite’ these files, usually when a system has been rebooted or an IISReset has been run. To make changes directly, it is recommended to use the SPWebConfigModification class and write your own feature to do these changes since once made, SharePoint will manage the changes and add them should a new server be added.

A good overview (for SP2010) can be found here: http://msdn.microsoft.com/en-us/library/bb861909(v=office.14).aspx – writing the feature is covered here: http://blog.beckybertram.com/Lists/Posts/Post.aspx?List=5489bebf%2Dbd8d%2D4a6f%2D995b%2D3a0a456796f6&ID=131&Web=316c15c2%2D6bc0%2D464f%2Dbda1%2D7ba96b4ba453

Be forewarned – SPWebConfigModification has a ‘Permanent’ setting; this really means permanent so this should never be used (SharePoint must be uninstalled to actually remove these entries).

Part 1 – Settings

Three settings are required for the process:

1) The LDAP Path used for Active Directory
2) The name to use for the AD Connection
3) The name to use for the Membership Provider

The LDAP Path

Most important is the Lightweight Directory Access Protocol (LDAP) path – this can be assumed based on the domain – for example, demo.com but should be double checked via the Active Directory management console. LDAP is actually not that complicated – it’s simply a ‘path’ to identify a user, computer, etc. The path is used to identify the specific ‘object’:

For this process, the only thing to be concerned about is the OU and DC’s needed for the connection. Login to the Domain Control and open Active Directory Users and Computers – from there the DC’s (and OU’s) can be determined:

From the example above, the LDAP path is quite simple: dc=gglportmon,dc=com (note, never use spaces). If an Organization Unit (OU) was in use, for example “SPUsers”, it would appear as a folder (like Users shown) and is included in the path, for example ou=SPUsers,dc=gglportmon,dc=com.

The AD Connection

The AD connection is the connection to the LDAP path that will be added to the web.config files for the SharePoint Site – the name is not important but must be consistent across all entries made. In this example, “adconn” is used.

The Membership Provider

The membership provider is simply a name that will be used when setting up a SharePoint Claims Based site. This can be any name though like the AD Connection, it must be consistent. In this example, “admembers” is used.

Part 2 – Setting up the Security Token Service

The Security Token Service (STS) is a specialized Web service that is designed to respond to requests for security tokens and provide identity management. This service is specifically used for trusted claims based authentication and can use simple to complex types of authentication. See the overall background here: http://technet.microsoft.com/en-us/library/ee806864(v=office.14).aspx

For the purposes of setting up “AD based FBA” however, the only changes required are adding entries to the web.config file of the STS Application. While the SPWebConfigModification method should be used, in this example, it is done manually.

First, locate the ‘root’ folder of the STS application; while it is usually in the same place, it should be checked since it may not be. To check this, login to the SharePoint Web Front End (WFE) hosting the SharePoint Central Administration site – once there, open the Internet Information Services (IIS) management console. Right click on the SharePoint Web Service and select Explore:

By default, this should open the folder <drive>:\Program Files\Common Files\Microsoft Shared\Web Server Extenisons\14\WebServices\SecurityToken:

In this folder is the ‘web.config’ file to be edited (note that by default, the file extension is not shown). Before ANY editing, make a backup of this file (above, a simple zip was created). Two completely new sections need to be added to this file – the connectionStrings and system.web sections. These are added directly in between the </system.net> end tag and the </configuration> end tag in the existing file as follows:

<add name="adconn"

connectionString="LDAP://gglportmon.com/DC=gglportmon,DC=com" />

</connectionStrings>

<system.web>

<add name="admembers"

type="System.Web.Security.ActiveDirectoryMembershipProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"

connectionStringName="adconn"

enableSearchMethods="true"

attributeMapUsername="sAMAccountName" />

</providers>

</membership>

</system.web>

Note that in these entries, the “AD Connection” name (adconn) and the “Membership Provider” name (admembers) are specified. Visually in the file, this should look like this:

Once these changes are made, save and close the file. To double check the service, run IISReset then browse to Central Administration. Use the IIS Management Console to ensure that the SharePoint Web Service site has not stopped – if it has it means an error in the web.config file; double check the entries and in worst case, restore the web.config from the backup and try again.

Part 3 – Setting up Central Administration

Setting up the Central Administration web.config requires three entries; remember that all naming must match for the connection and membership provider; as always, make a backup of the web.config before modifying it.

First Update

The first part to add is the connection string – this is added directly after the </SharePoint> tag:

</connectionStrings>

Visually in the file, this should look like this:

Second Update

The next section is to update the “PeoplePicker” section of the web.config – this enables the SharePoint People Picker dialog box to find the AD users via the new connection. In the file search for the “PeoplePickerWildcards” section then under the <clear /> tag, add a new key value:

Visually in the file, this should look like this:

Third Update

The last update is to create the membership section – this will create the actual “provider” and make it accessible for Central Administration. This section updates the existing one in the CA web.config file (located directly below the </roleManager> end tag. By default, this section looks like this:

</providers>

</membership>

Edit this and add the new provider as shown:

<add name="admembers"

type="System.Web.Security.ActiveDirectoryMembershipProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"

connectionStringName="adconn"

enableSearchMethods="true"

attributeMapUsername="sAMAccountName" />

</providers>

</membership>

Visually in the file, this should look like this:

Once these changes are made, save and close the file. To double check the service, run IISReset then browse to Central Administration. If there are any problems with the web.config, it will be reported. Double check the entries and try again. Worst case, restore from the backup file and try again.

NOTE: Depending on the setup, an error may redirect to the default SharePoint error page thus masking what the real issue may be. To properly ‘debug’ the issue it is necessary to enable debugging in SharePoint. In the SharePoint Hive (usually c:\program files\common files\microsoft shared\web server extensions\14, but the installation may be different), open that folder and locate and open the TEMPLATE folder then the LAYOUTS folder. In this folder, there is also a web.config file. Edit this file and locate the <customErrors tag and change the mode from “On” to “Off”:

Run an IISReset then attempt to browse to Central Administration again – this time the full ‘stack trace’ of the error will appear. Any specifics on errors in the web.config file will be displayed.

Part 4 – Setting up the Site

The next activity is to setup the actual site (through CA) and to modify the web.config of that site to accommodate the AD membership provider.

Creating the new Application – Part 1

Navigate to the Central Administration site then click Manage Web Applications; when there, click New Application. On the New Application page, select Claims Based Authentication then set the Port number the site will run under (set the number then click outside of the box). If desired, specify a different name than the default:

Creating the new Application – Part 2

Scroll down the New Application page to the “Claims Authentication Types” section. For the initial setup, it is recommended that ‘Enable Windows Authentication’ be left checked – when working, this will enable either Windows or FBA to be selected when logging in. When the site has been tested, this can be disabled (see Part 4 below).

Click to select ‘Enable Forms Based Authentication (FBA)’ then under the ASP.NET Membership provider name, enter the name used for updating the web.config files – in this example, ‘admembers’ as shown:

Scroll down and select to create or use an existing application pool then set the Database name as desired (the default will be “WSS_Content” or “WSS_Content_<SiteGuid>”); it is recommended this be done so that the database is easily identified in SQL Server (i.e. “WSS_Content_Site80).

Click OK to create the application. When done, navigate to the “Inetpub” directory – by default, SharePoint sites are created under the folder c:\inetpub\wwwroot\wss\VirutalDirectories\<port number> - in the example above, port 80 was used:

Notice that a folder called _forms is under this folder and the site web.config has been created. The _forms folder is where the site Login Page is stored (called ‘default.aspx’) – this file can be modified to add branding, etc. Note that if this file is modified in a multi-server farm that is already configured, the modified file must be copied to all front end servers. If modified during setup, it will be copied automatically when additional servers are added.

Creating the new Application – Part 3

The next activity is to update the newly created site web.config file. The changes here are similar to those made for the Central Administration web.config.

Updating the Web.confg –Part 1

Make a backup of the web.config in the site folder (under inetpub) then open in an editor. Find the </SharePoint> end tag and add the following between the </SharePoint> and <system.web> tags:

</connectionStrings>

Visually in the file, this should look like this:

Updating the Web.config – Part 2

Visually in the file, this should look like this:

Updating the Web.config – Part 3

The final change in the web config.is to update the Membership provider section; this section is added when Forms Based Authentication was set when creating the application. In the web.config file, search for the <providers> tag. Under the <add name=”I” line already included, added the following:

<add name="admembers"

type="System.Web.Security.ActiveDirectoryMembershipProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"

connectionStringName="adconn"

enableSearchMethods="true"

attributeMapUsername="sAMAccountName" />

Be SURE that the name used (admembers) is the same as was used when creating the application (and added to the other web.config files). Visually in the file, this should look like this:

Creating the new Application – Part 4

Use of Windows Authentication can be removed after the site is operating properly. Disabling this is done by navigating to the Central Administration Site, clicking Manage Web Applications. On the Web Applications page, click to select the site created then in the ribbon click “Authentication Providers”. Click the ‘Default’ link on the popup to open the Web Application page. Scroll down the New Application page to the “Claims Authentication Types” section, uncheck ‘Enable Windows Authentication’ then scroll down to click OK. Opening the site (to show the Login Page), the ‘drop down’ will no longer appear indicating that the site is only using FBA.

Monday, March 25, 2013

DELL PowerEdge - popup.exe MSVC71.dll missing

When cleaning up a server the other day (trying to get Hyper-V installed - so far, not successfully), I came across a dumb error on start up of the server. Popup.exe was indicating that "MSVC71.dll" was missing.

Not exactly sure how that happened however...

1) Get a copy of the DLL from any of your systems (even your laptop) running x64
2) Don't bother dropping into c:\windows\system32 - that does not fix the problem
3) Locate the Popup.exe - in my case it was in C:\Program Files (x86)\Dell SAS RAID Storage Manager\MegaPopup
4) Drop the DLL in there (don't bother to register, i.e. Regsrvr32 - not needed)
5) Reboot

Voila - problem solved.

Friday, February 8, 2013

Configure Apps for SharePoint 2013 and unable to set DNS CNAME record

Following up a great post by Gauray Mahajan in configuring Apps for SharePoint 2013 - this is the 'back side' of the App setup done through Central Administration and absolutely necessary for your Apps to work. You can read his Post here.

In the basically four steps he outlines - setting up DNS, enabling the services then setting up the Application Services and Proxies (using PowerShell*). If you follow his instructions to the letter, it will all work.

However, one issue I came across a few times is in setting up CNAME record in DNS. If you follow his instructions, it may or may not work so here's how to get around it.

When you first setup the DNS CNAME record (as he outlines), the entry will look like this (in my case, the DNS is simply SP13DEMO.com:

When you click OK, you might unfortunately see this message when you try to save the record:

So this tells you a lot right? Right. So after a little checking around, this somewhat generic message really won't help even though it is properly set so here's the work around. When you first create the CNAME record, don't specify the FQDN:

Click OK to save the record (this should work). Once it is created, right click on the new entry and select Properties - when the popup appears you can now specify the FQDN (in my case again, this is simply SP13DEMO.com. Click OK and the record will be updated properly!

OH - One other thing; in some cases I've had to reboot the Front End server to make sure it picks this up (before you start the work there).

* I think PowerShell is great - however I think it is extremely lazy on MS's part to defer to it when setting up crucial services instead of enabling these through the UI. Not to mention, it hampers developers (who generally don't have this access) and means the Administrator has to spend a lot of time learning it. While in the Developer Kitchens in Redmond, I did voice this issue - someone at Microsoft REALLY likes to type or never got out of their Unix/Linux command line habits!

Thursday, January 31, 2013

SharePoint 2013 Event ID 2163

After installing SharePoint 2013, you might come across an issue where you see an Application Event ID 2163 start popping up. While it may seem innocuous, it actually will cause multiple problems down the road.

The error is effectively telling you that the SharePoint Tracing Service is not able to write to the SharePoint log folder; when it cannot, it will write to the account local folder (under AppData). This means the service will not really work because the local user folder is not accessible to other SharePoint accounts and services.

The Event ID 2163 error message will be something like this:

Tracing Service failed to create the trace log file at location specified in SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\15.0\WSS\LogDir. Error 0x0: The operation completed successfully. . Traces will be written to the following directory: C:\Users\SPSERV~1\AppData\Local\Temp\.

In the System Application Event log, the message looks like this:

As you can see, the account that's having the problem is indicated. Sorting this all out is pretty simple - what it really means is simply that the account running the service (SPService as shown) doesn't have permissions to write to the SharePoint Log file directory.

If you open up the Services (Start > Administrative Tools > Services or Start > Run... then enter services.msc and click OK) and locate the SharePoint Tracing Service, you can determine the account in use:

The confusing part about the message is that it indicates not the physical path to the log files but the Registry setting (HKEY_LOCALMACHINE/Software/Microsoft/Shared Tools/Web Server Extensions/15.0/WSS) - remember, by default, the SharePoint logs are located in c:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\Logs but if you are working in a production environment, the logs are probably (or should be) located elsewhere. You might already know where they are but if you don't, you can easily use the setting to find them - if you open the Registry editor (Start > Run... then enter regedit then click OK) then follow the path, you will see the "LogDir" setting (FYI don't make any changes here):

As you can see, this is the default setting - %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\15\LOGS\ - that is, the default path mentioned above.

Using Windows Explorer, navigate to the location specified - (by default, c:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\). Right click on the folder and select Properties then click the Security tab:

As you can see, the account in question here (SPService) is a managed account and would NOT be a member of the Administrators group so by default, it has no access here. Click the Edit... button, add the account and give it Full Rights to this folder:

Click Apply then OK then close out the properties window (Side note: it is not a bad idea to add the SharePoint Farm account with full permissions here).

Once this is completed, a reboot is suggested but not necessary and may not be possible in a production environment; you can optionally use the Services (Start > Administrative Tools > Services or Start > Run... then enter services.msc and click OK) - right click on the SharePoint Tracing Service and select Restart:

Problem solved!!

About us:

Sterling International Consulting Group is a specialist in enterprise systems including architecture, governance, business continuity, and disaster recovery planning with over 28 years in IT and management consulting. SICG also has a dedicated practice in SharePoint Technologies and Microsoft Technologies. From planning to analysis to development to deployment, SICG has the experience and knowledge to understand the best for your business – find out why: sicg@sterling-consulting.com – www.sterling-consulting.com.

Keep up with the latest articles and tips around SharePoint from author & CEO David Sterling via http://www.sharepoint-blog.com and his personal blog site:http://davidmsterling.blogspot.com or contact him directly at david_sterling@sterling-consulting.com.

Sunday, January 27, 2013

SharePoint 2013 AppFabric Event ID 1000 and Event ID 1026

In working SharePoint 2013, you may come across an issue with the permissions with the AppFabric when it is first setup. You might notice the problem right away or you may not - usually, it becomes obvious when things aren't working (like creating a site fails, etc.).

Most notably, if you check the System Event Application log, you'll see these errors repeating over and over:

Event ID 1000
Faulting application name: DistributedCacheService.exe, version: 1.0.4632.0, time stamp: 0x4eafeccf
Faulting module name: KERNELBASE.dll, version: 6.1.7601.18015, time stamp: 0x50b8479b
Exception code: 0xe0434352
Fault offset: 0x0000000000009e5d
Faulting process id: 0x524
Faulting application start time: 0x01cdfcb5fdb726f2
Faulting application path: c:\Program Files\AppFabric 1.1 for Windows Server\DistributedCacheService.exe
Faulting module path: C:\Windows\system32\KERNELBASE.dll
Report Id: 13afe590-68aa-11e2-9254-000c2950c2a6

And the second:

Event ID 1026
Application: DistributedCacheService.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: Microsoft.ApplicationServer.Caching.DataCacheException
Stack:
at Microsoft.ApplicationServer.Caching.VelocityWindowsService.StartServiceCallback(System.Object)
at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()
at System.Threading.ThreadPoolWorkQueue.Dispatch()

FYI: Side note here - this fix applies to ALL uses of AppFabric with this problem, NOT just SharePoint.

You'll notice a couple of things here as well - you will find that the AppFabric Caching Service (using Start > Administrative Tools > Services) is set to Automatic but it's stopped and if you try to start it, the above errors will occur and the service will stop (the same errors above repeated in the System Event Application log).

The problem here is that it effects a bunch of stuff in SharePoint; for example, creating new Site Collections will fail. Attempting to deploy web parts and solutions will fail too. As well, if you check the SharePoint ULS log (c:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\logs), you'll see some errors like this:

SPDistributedCacheClusterCustomProvider:: GetValue(...)

Fail to load running IIS site with the error Access is denied

Unknown SPRequest error occurred

Using some of the AppFabric PowerShell commands (open the AppFabric PowerShell via Start > All Programs > AppFabric for Windows Server > Caching Administration Windows PowerShell), you can check the status of the 'host' using Get-CacheHost. When this displays, you'll see that it indicates a status DOWN. Using other cache commands, such as Start-CacheCluster won't work either - they will simply timeout.

This was a tough one to track down - searching for the errors through Google/Bing and the rest, there are lots of possible solutions - few that drive to a solution. However, many indicated that the error is somehow permissions based - something also indicated in the SharePoint Log (i.e. the 'Access is denied' message). After many, many hours, we tracked down the final cause - it appears that when any one of the Application Pool accounts does not have proper access to either SQL or proper rights on the front end web server, this is the result.

To fix the problem, do the following:

To begin with, check your SQL Server settings - open SQL Sever Management Studio (08 or 12), expand the Server name, then expand Security. Find the account being used for the Application Pool, right click on it and select Properties.

Under the User Mapping tab (left side), verify that the it has rights to the database used for the Application Management Service database (you can find what that is called using Central Administration > Manage Service Applications) AND that it has been granted SPDataAccess rights (double check the rights, make sure SPReadOnly is NOT checked).

Do this for ALL application pool accounts.

Return to the server and try to start the AppFabric service again. If it does not work (in our case, it did not), it turns out that it is actually in the permissions settings on the Web Server itself.

Log in to the front end server and select Start then right click on Computer and select Manage (or Start > Administrative Tools > Server Manager).

Expand the options then expand Configuration then expand Local Users and Groups.

First, find the WindowsFabricAdministrators group and make sure that the SharePoint Farm account is a member - if it is not, add it.

Next, for each of the application pool accounts, make sure they are members of the following groups:

IIS_USRS
WSS_WPG
WindowsFabricAllowedUsers

The last one was the key - once the Application Pool accounts were added to that group, the AppFabric service started all by itself - no more errors!

UPDATE:
It appears this error can also be caused by a quirk in AppFabric - it appears that this error can ALSO be caused if using a HOSTS file instead of DNS. If you are using the HOSTS file, you should make sure that the Fully Qualified Domain Name is used - i.e. <server>.<domain>. So if you have in the hosts file:

10.0.0.10 MyServer

It should be:

10.0.0.10 MyServer.Mydomain.com

About us:

Friday, January 25, 2013

SharePoint 2013 Uninstall and AppFabric Woes

At some point either during development or setup of a farm, you might have to remove SharePoint 2013 and re-install. Like 2010, the SharePoint uninstall does so pretty cleanly but with some caveats.

For one (just like 2010), the SharePoint databases are not removed. This is so that you can remove a server from the farm without affecting others. However, if you are truly removing SharePoint (i.e. a single server or to do a re-install), you have to manually delete all of the DB’s created for the various services, etc. directly using SQL Server Management Studio. This includes the SharePoint Config database.

However, SharePoint 2013 also installs a number of other services within the SharePoint 2013 Products Preparation Tool – one of these happens to be the Microsoft AppFabric 1.1 for Windows Server. AppFabric was developed for Azure and is a set of integrated technologies that makes it easier to build, scale, and manage Web and composite applications that run on IIS. SharePoint 2013 makes use of these services (thus why required) through the Distributed Cache Service.

When removing SharePoint 2013, it can have an adverse impact on the AppFabric setup. SharePoint creates its own ‘Cache node’ to coincide with SharePoint. This directly affects the web.config files across the system and sites. It doesn't ALWAYS happen but when it does, it’s a real pain.

The problem comes in when you attempt to re-install SharePoint; it would appear that the AppFabric settings are not picked up during the new installation which unfortunately causes both to fail. You can get SharePoint installed, but you’ll see problems when you attempt to add Services like the Access Service. Unfortunately, SharePoint simply gives you one of those simplistic “error has occurred” pages and looking into the ULS log doesn’t give you much. In most cases, it will simply indicate ‘access is denied’ even when you are logged in as the Farm Administrator account.

If you do have this problem, the quick fix is here is to uninstall SharePoint then uninstall AppFabric 1.1 but of course, there is a gotcha. If you attempt to remove the AppFabric, it will indicate that it will not delete the existing configuration (i.e. settings in the web.config files).

So, I am not a big fan of messing with web.config files, especially with SharePoint (since it keeps the web.config in the DB anyway), it turns out Microsoft was wise enough to provide us with a UI tool to do this. Full details can be found under the MSDN article here: http://msdn.microsoft.com/en-us/library/ff637683(v=azure.10).aspx.

More useful are the cleanup instructions found here: http://msdn.microsoft.com/en-us/library/ff637741(v=azure.10).aspx – in this article, it includes a link to the AppFabric Uninstall Cleanup Tool – this is a small application that will do the cleanup for you and prevent having to manually edit anything.

So you might think you are all set – au contraire! Turns out that the AppFabric uninstall has a bug! Oh what fun!

So to sum it up, a proper uninstall/re-install (again, when you have this problem – if the AppFabric is working, no need for this) is as follows from start to finish:

1) Uninstall SharePoint 2013 from the web front end

2) On SQL Server, delete any databases that were created by the previous installation (or locally if using SQL Express)

3) Uninstall AppFabric 1.1 from the web front end

4) Use the AppFabric Uninstall Cleanup Tool to remove the web.config entries (again on the web front end server)

5) Reboot the web front end server

6) Login to the front end server and from the SharePoint 2013 Setup, run the SharePoint 2013 Products Preparation Tool – this will detect that the AppFabric is missing and try to install it again

7) When the process completes, it will ask for a reboot; on restart it will start up again – however here’s where it gets tricky:

a) If the process runs through, starts up on reboot and simply finishes, you are fine.

b) If the process starts up again and tries to install the AppFabric (again) then asks for a reboot, the problem is that the AppFabric uninstall didn’t complete. In effect, the Prep tool will continually run at startup and ask for a reboot every time (but AppFabric WILL NOT be installed). So when this happens, you have to do some additional steps to clear it out:

i) First verify in the Prep Tool message window that there were no changes

ii) Open the “Start” folder (All Programs > Start), right click on the Microsoft SharePoint 2013 Products Preparation Tool link and delete it (Or you can do a reboot and when the Prep tool restarts, click Cancel):

iii) Reboot the server – the Prep tool should not restart

c) Now back to why AppFabric has a problem – it turns out that in the background, the AppFabric installation is failing with an “MSI Error 1603 installing AppFabric 1.1” (you’d see that if you tried to install AppFabric by itself) – to fix this:

i) Open the Registry Editor (Start > Run… > Regedit) (disclaimer: make a backup before you make changes – if you don’t know how, you should get someone that does!)

ii) In the registry editor, find the ‘PSModulePath’ ** key HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Control/Session Manager/Enviroment/PSModulePath – you can search for PSModulePath but make SURE you have the path correct (there is more than one!)

iii) Delete the PSModulePath key:

iv) Reboot the server

v) Login to the front end server and from the SharePoint 2013 Setup, run the SharePoint 2013 Products Preparation Tool – this should again detect that the AppFabric is missing and try to install it again – when complete it will request a reboot

vi) On the restart, login again – this time the Prep tool should complete and when you click Finish will NOT require a reboot

** BTW: Kudos to Lucas Massena for finding the AppFabric 1.1 uninstall bug fix: http://social.msdn.microsoft.com/profile/lucasmassena/?type=forum&referrer=http://social.msdn.microsoft.com/Forums/en/velocity/thread/561f3ad4-14ef-4d26-b79a-bef8e1376d64

8) When the Prep tool completes successfully, you can re-install SharePoint from scratch including creating new databases for the install

Good luck on this one!

About us:

SharePoint 2013 Application Pool Account User Profile

As was true with SharePoint 2010, it is very important that the account used for the SharePoint Application pools has a valid Domain User Profile to operate. This is particularly needed in 2013 as it can cause issues when deploying applications.

The error appears in the Event Application Log on the SharePoint front end server. Usually indicating that the account (the application pool account) was logged in with a temporary profile and that all changes will be lost when logged out (the account name is specified in the error).

Fixing this issue is usually easily done simply by logging into the SharePoint front end console (i.e. ON THE BOX) with the application pool account. Assuming all is well, a new profile folder is created in the c:\Users folder. If needed (though this doesn’t always work), you can add the account to the Remote Desktop Users group and try to use Remote Desktop to login that way (remember to remove that right after the fact!).

However, that does not always fix the problem – I’ve had cases where even after repeated login attempts, the error still shows. As well, when logging in with the account, Windows will show a quick ‘popup’ message that indicates it is using a temporary profile. Further, if you reboot the SharePoint server (or run an IISReset), you may still see the Event Application Log error when a SharePoint site is opened (i.e. the application pool is ‘logged in’).

First of all, changing the account or permissions won’t fix the problem – what it means is that there is a corrupt profile for that account. Second, the problem will not fix itself.

I’ve used many ways to correct the problem but found the “perfect” fix:

Quick disclaimer: Backup the registry before you edit it or work with someone that knows how to use it properly.

Start off using an administration account and repeat the following process for every server in the farm (note: I've had to do this on the Domain Controller too!):

a. Open the C:\Users folder and look for a folder under the same name as the account (i.e. SPAppPool) – if you DO NOT see it, log out and go on to the next server

b. Zip the folder up if you want to (though not necessary) and delete the folder

c. Using Start > Run… to open a command line (and so you are running as administrator), enter REGEDIT and run it

d. When the Registry Editor opens, open the following subkey: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList

e. Under this subkey, you will see a list of the accounts – each Key is based on the “SID” (the unique ID) for each account profile:

f. When you select each subkey, you will see the name of the account under the “ProfileImagePath” value – find the one that belongs to the application pool account and delete the entire key (right click on the S-1… key and select Delete) then close out the editor

When you have completed the above on every server in the Farm, do the following:

Next log in to the SharePoint front end server using an Administrator account
Click Start then right click on Computer and select Manage – this will open the Server Manager page (or click it in the tool bar if available)
Expand Configuration then Local Users and Groups then expand Groups
Right click on the Administrators group and select Add to Group – add the application pool account in question
Log out of the server and log back in using the application pool account (it should take a few minutes); when the user profile is created and desktop setup, you should see the standard Server Manager page that pops up for Administrators (you can close that)
Open Windows Explorer and open c:\Users – verify that the account you are logged in as has a new folder there (that indicates the profile was created successfully)
Assuming all is well, log out and log back in with an Administrator account
Click Start then right click on Computer and select Manage – this will open the Server Manager page (or click it in the tool bar if available)
Expand Configuration then Local Users and Groups then expand Groups then the Administrators group
Remove the application pool account in question

Note that if you added the account to the Remote Desktop group, you should remove it.

Once you have completed, you can verify that all is well:

Login to the SharePoint front end using an Administrator/Farm account
Close any open browser windows
Clear the Event Application log (if you can)
Use the Start > Run… command (so you are running as an administrator), enter iisreset and click OK
Open the Central Administration site
Check the Event Application log (refresh if you have to) and verify that the error is no more

Hire Me!

Search This Blog

Sunday, May 19, 2013