* Though this topic is very simple and highly recommended approach in the enterprise deployments, I have seen many deployments which are not following this approach. E.g.: Using SQL client alias for SharePoint installations will be really useful if you want move all databases to another SQL Server by just making alias change point to the new SQL server.
* In this post I’m going to cover how we can install & configure SharePoint 2013 Preview with SQL Client Alias. Though this post is talking about SharePoint 2013 preview, the underlying concept will be same for SharePoint 2010 & SharePoint 2013 RTM.
* In my test lab, I have total four virtual machines configured. This post is based on a SharePoint small server farm for setup and proof of concept. I will refer to this same environment in my future blog posts, there will be more servers adding to the existing server farm.
litdc : is the domain controller and AD server (domain : litware.local), this machine is installed with Windows 2008 R2 + SP1
litsql1 : is the SQL server machine which is installed with SQL Server 2012 RTM with Windows 2012 Server Release Candidate.
litsp1 : is the one of the SharePoint Servers, I’m configuring this server with WFE role. This server is installed with SharePoint Server 2013 Preview with Windows 2012 Server Release Candidate.
litsp3 : is the one of the SharePoint Servers, I’m configuring this server with Application role (central administration and other services). This server is installed with SharePoint Server 2013 Preview with Windows 2012 Server Release Candidate. Name of the server is litsp3 as I’m planning to add one more SharePoint Server litsp2 to with WFE layer later.
In this post I’m only concentrating on the part of configuring SharePoint Servers with SQL Client Alias.
# Step 1
To harden the security for SQL server it is highly recommend to install SQL Server with named instance with custom port and block all default SQL specific ports. So, that is our first step to consider while setting up the SQL Server.
While installing the SQL Server in litsql1 server I have installed it with named instance “litsql1sql1”.
* After the installation of SQL Server with named instance, we have to assign a custom static port number for the SQL Service. You can do this in “SQL Server Configuration Manager”.
* We have to configure it by taking the TCP/IP properties of “Protocols for SQL1 (SQL1 instance name)”. By default, whenever we install SQL Server with named instance it will assign a “TCP Dynamic Port”, we have to clear it out in the same location (just before TCP Port).
After doing the above step, we have to restart the “SQL Server Service” to use the newly assigned port.
To confirm the usage of the new port, you can either look at the SQL Server Logs in the SQL Server Managements studio or can look at the windows application event logs directly.
# Step 2
Once the above port validation is over the next important step is open the custom port for In bound connections if you have firewall enabled. Just need to create a new Inbound Rule for allowing connections for the custom port, in my case it is “65000”
# Step 3
Alright, now we can go to SharePoint side.
* In my case there are two SharePoint Servers to be configured, one WFE – litsp1 and one Application Server – litsp3.
* Since I’m going to host central administration in litsp3,
* I’m going to configure this server first. Main configuration needs only before running the PSConfig. * I have installed SharePoint 2013 Preview in both of these servers initially.
Before running the PSConfig , we have to configure the SQL Client Alias. There will be two versions of cliconfig in 64 bit operating system.
C:WindowsSystem32cliconfg.exe – 64 bit version of cliconfig.exe
C:WindowsSysWOW64cliconfig.exe – 32 bit version of cliconfig.exe
SharePoint 2010 & 2013 are 64 based so we have to configure the 64 bit version of cliconfig.
* In my test case I have created alias “spsql” with network library type “TCP/IP” (don’t use named pipes).
* In the Server Name textbox we have to give the SQL Server name (litsql1) and then uncheck the “Dynamically determine port” option and give the custom port number, in my case “65000”. After saving the changes you can validate the registry settings to make sure that it is applied correctly.
# Step 4
* At this point we are good to run SharePoint PSConfig and provision a new server farm.
* While creating a new farm, provide the SQL Client Alias “spsql” instead of the the SQL Server Instance name “litsql1sql1”.
* After finishing the PSCofig tasks, central administration site will be provisioned the SQL Server name will be used as “spsql”.
* To connect other servers to the SharePoint farm we have to repeat step #3 in all servers. In my test lab I have one more server to be added to the same farm.
If you block UDP port 1434 or TCP port 1433 on the computer that is running SQL Server, you must create a SQL Server client alias on all other computers in the server farm. You can use SQL Server client components to create a SQL Server client alias for computers that connect to SQL Server.
To configure a SQL Server client alias
Verify that the user account that is performing this procedure is a member of either the sysadmin or the serveradmin fixed server role.
Run Setup for SQL Server on the target computer, and install the following client components:
Open SQL Server Configuration Manager.
In the navigation pane, click SQL Native Client Configuration.
In the main window under Items, right-click Aliases, and select New Alias.
In the Alias – New dialog box, in the Alias Name field, enter a name for the alias. For example, enter SharePoint_alias.
In the Port No field, enter the port number for the database instance. For example, enter 40000. Make sure that the protocol is set to TCP/IP.
In the Server field, enter the name of the computer that is running SQL Server.
Click Apply, and then click OK.
Verification: You can test the SQL Server client alias by using SQL Server Management Studio, which is available when you install SQL Server client components.
Open SQL Server Management Studio.
When you are prompted to enter a server name, enter the name of the alias that you created, and then click Connect. If the connection is successful, SQL Server Management Studio is populated with objects that correspond to the remote database.
To check connectivity to additional database instances from SQL Server Management Studio, click Connect, and then click Database Engine.
There are many great articles that talks about how to configure your SharePoint 2013 farm for apps development. At the end of this article I will list a lot of these great references. I’m going to try to summarize the important things you need to know and also cover few FAQs along the way.
First of all, you need to know that there are two main types of SharePoint apps you can develop on prim in your local SharePoint 2013 farm:
SharePoint hosted apps
SharePoint provider hosted apps
The third type SharePoint Auto hosted (Azure auto hosted apps) is only available on SharePoint online tenants part of Office 365. Also it’s important to note that if you plan to publish your SharePoint app into the SharePoint store to make some money the above mentioned types (Hosted & provider hosted) are the only allowed ones as long as they don’t request full control permission. For more details about the submission requirements check this link.
In order to make your SharePoint 2013 farm ready to develop and deploy apps you need the following:
Turn oncreate required services and service applications
Configure DNS records along with SharePoint Web Applications
Configure required service applications
Prepare your toolsenvironment
I’m going to go through the above steps quickly.
First: Turn onCreate required services and service applications
You need to turn on the following services:
App Management Service
Microsoft SharePoint Foundation Subscription Settings service
Next step is to create the following service applications:
1. App Management Service Application:
This service application is responsible of tracking app licenses and app permissions …etc. This service application can be created from Central admin or via PowerShell.
2. Subscription settings service:
This service is responsible of generating the apps url, it also maintains tenants subscriptions in a multitenant deployment. This service application cannot be created from Central Admin. You will need to use PowerShell commands to create it. Use the following commands Article>:
# Gets the name of the managed account and sets it to the variable # $account for later use
$account = Get-SPManagedAccount “”
# Create an application pool for the Subscription Settings service application. # Use a managed account as the security account for the application pool. # Store the application pool as a variable for later use.
# Create the Subscription Settings service application, using the # variable to associate it with the application pool that was created earlier. # Store the new service application as a variable for later use.
is the name of the managed account in the SharePoint farm.
is the name of the Subscription Settings service database.
At the end of this step I want to mention that you have to start and create these two service applications to enable apps deployment and development in your farm. So this step is mandatory in case you are wondering.
Second: Configure DNS records along with SharePoint Web Applications
Since I’m talking about a development environment here, I’m going to assume that your dev box is hosted in your company’s domain or at your local virtual environment. So you will not need to purchase any domain names or anything. This step confuses a lot of developers specially the ones who don’t have a lot of experience in with windows domain and active directory services. To keep it simple I’m going to suggest a specific setup that you can follow.
There are two things you need to touch in this step:
Central Admin (probably)
First thing you need to do is to setup the required domain names you are going to use for your apps and SharePoint sites …etc. You will need a separate domain name for your apps (recommend to be totally separate and not a sub-domain of a domain you use to host SharePoint applications that will use the apps – this is for security physical isolation purposes). Let’s dig a little deeper into this:
I want to have one domain name created for my intranet:
I want to have another domain name created for my apps:
Note: I’m using the same IP-address for both domain names since I only have one SharePoint box in my 2013 farm and one network card (NIC).
I will use my Intranet site (which is a team site) for developing my apps. So I will use the root site collection under that Sharepoint application to deploy and debug my apps.
In order to create these domain names you need to login to your domain controller and open DNS manager. First thing you need to do is to create the domain name for Intranet. To do this follow the steps:
Expand Forward lookup Zones then select your domain SWRanger.com
Then right click on the selected domain node
Select net Host (A or AAAA)… option
Enter the name Intranet
Enter the IP-Address (SharePoint box IP address) 192.168.0.113
Hit Add Host
Now the next step is to create the apps domain name and have it point to the SharePoint box, follow the steps:
Right click on Forward lookup zones the select New Zone
In the New Zone Wizard click Next.
In the Zone Type page click Next.
In the Active Directory Zone Replication Scope page, select the appropriate replication method then click Next (The Default setting is fine in dev environments with one DC).
In the Zone Name page, in the Zone name box type the name for your new app domain name Apps.com, and then click Next.
The New Zone Wizard shows the new domain name for apps.
On the Completing the New Zone Wizard page, review the settings, and then click Finish.
Now you need to create a wildcard alias for the new apps domain name so that SharePoint can generate any alias (app instance id) under your domain and still resolve to your SharePoint server. Follow the steps:
Expand Forward Lookup Zones
Select your new Apps domain Apps.com
Right click and select New Alias (CNAME)
Type “*” in the Alias name field
Under Fully qualified domain name (FQDN) for target host: Click Browse
In the Look in field select your domain name that contains your intranet domain name
In the Records section double click on the records until you find your Host (A) record pointing to your intranet site Intranet.yourdomain.com
Select your intranet domain name Intranet.yourdomain.com
Now your DNS records are ready. All you need to do is to make sure that you have the appropriate settings on IISSharePoint so that IIS will listen on your apps domain name Apps.com and rout the request to a SharePoint application which will redirect your app accordingly.
Before we configure IISSharePoint you want to make sure that your DNS configuration for the App domain name is working properly. To test that, ping the new apps domain name with a random sub-domain for instance ping the following: abc1234567.Apps.com if you get a response back with the IP Address of your SharePoint box that means you are golden and ready to go to the next step.
In this step instead of changing IIS settings by adding more bindings to an existing site (if possible) we will just create a new SharePoint application on port 80 that doesn’t have a host name. This way this SharePoint application will work as a catch all for any DNS name created for the deployed app instances. Here are the important settingsconfiguration for the new SharePoint application you will create:
Name: Anything – I would call it something that identifies it as a catch all for apps requests
Claims Type: Enable Windows Authentication | Integrated Windows authentication | NTLM (Note SharePoint Apps don’t support ClaimsKerberos combination)
App Pool: Use the same account as the one used for your SharePoint Applications that will use the apps or an account that has access to these SharePoint application’s content databases
Database Name: Anything – We will not create any site collections for this SharePoint application nor will need a content db. So make sure you remove this content database after the application is created
This step is complete now.
Third: Configure required service applications
Now you are ready to configure your App Management settings for the farm. Follow the steps below:
Open Central Admin
Navigate to Apps from the left nav then click on App Management | Configure App URLs
Enter the App DNS you created in the previous step Apps.com in the App domain field
Enter an App prefix, in my case I’m going to enter app
This step is complete. Now your farm is ready to deploy new apps.
Fourth: Prepare your toolsenvironment
There are few things you need to know about before your start developing apps for SharePoint. The two main thing I would highlight here are:
Use a Developer Site for deploying and testing your apps or enable the Developer feature
Visual studio 2012 will complain about a missing feature Developer if you attempt to deploy an application to a SharePoint site that is not created with the “Developer Site” template since it will be missing required lists and content types. So if you for example try to deploy your app (Using Visual Studio F5) to a team site or a publishing portal you will get the following error in Visual studio’s Error List:
Error occurred in deployment step ‘Install app for SharePoint’: Sideloading of apps is not enabled on this site.
In order to overcome this issue you need to enable the Developer feature on your Site collection where you want to deploy and test your apps using Visual Studio. Since this feature is hidden you will not see it in the list of the site collection feature, so you will need to enable it using PowerShell:
Don’t use Farm admin (System Account) to deploy and test apps
SharePoint will not allow you to install nor uninstall apps using the farm account (System Account). If you try to deploy your app using Visual Studio F5 you will get one of the following errors if you do it using System Account:
Error occurred in deployment step ‘Install app for SharePoint’: The System Account cannot perform this action.
Cannot perform this action
Sorry, something went wrong Please refresh the page and try again.
So avoid this issue you need to log in to SharePoint with a different account (not the farm admin) andor running Visual studio with a different account other than the farm admin. Since in SharePoint 2013 we have removed the Sign in a different user menu option, you can get to it through the following URL:
ErrorDetail: There was a problem applying the web template for the app web.
ErrorTypeName: App Related
ExceptionMessage: Feature with Id ‘23330bdb-b83e-4e09-8770-8155aa5e87fd’ is not installed in this farm, and cannot be added to this scope.
SourceName: App Web Deployment
Error occurred in deployment step ‘Install app for SharePoint’: Failed to install app for SharePoint. Please see the output window for details.
That error suggests that SharePoint is trying to activate a web scoped feature called AppLockdown feature on the app web but it couldn’t find that feature installed in the farm in the first place. All you need to do is to install that feature to the farm using PowerShell:
That is going to solve your problem.
When you try to deploy your app using a different developer account you used before or using a copy of the app VS project you get the following error:
Error occurred in deployment step ‘Install app for SharePoint’: The provided App differs from another App with the same version and product ID.
In order to overcome that issue, navigate to your target site collection and do the following steps:
Install the app if existed by navigating to Site Contents then hovering on the app and clicking Remove (Remember don’t do this with the System Account or it won’t work)
Navigate to Apps in Testing library and remove the app from there as well
Navigate to App Packages library and remove the app from there if existed
Lastly before I conclude here I would like to mention that you definitely want to plan to use SSL certificates to secure your SharePoint sites and apps traffic since they use clear text for the Auth tokens. It’s however not required, so your apps will work fine without SSL. That might be acceptable in in Dev environments but never acceptable in production. I’m planning to include the steps of configuring self-services SSLs in development environments soon.
With that you should have all the information you need to start developing SharePoint apps. If you have any questions please leave me a comment.