START or STOP App Fabric Caching service using PowerShell

START or STOP App Fabric Caching service using Power Shell

App Fabric or Distributed Caching service can be started using services console or from the central admin UI. However, I find it easy to start it using power shell. Copy and paste the below code in a notepad and save it as .ps1 file. The script file can be executed from the distributed cache server/s.

START App Fabric Caching Service

$instanceName =”SPDistributedCacheService Name=AppFabricCachingService”
$serviceInstance = Get-SPServiceInstance | ? {($_.service.tostring()) -eq $instanceName -and ($_.server.name) -eq $env:computername}
$serviceInstance.Provision()

STOP App Fabric Caching Service
Stop-SPDistributedCacheServiceInstance –Graceful

After the service is started, from the DC server, type the below two commands to ensure that your service is UP.

Use-CacheCluster

Get-CacheHost

Now about the verification. First verification should be in the services.

1. Click on Start > Run > type services.msc > Enter

2. Ensure the App Fabric Caching service is running.

The next verification is from the Central Administration.

1. Navigate to Central Administration > Click on services on server

2. Select the server from the dropdown where your DC is configured

3. Ensure the Distributed Cache status is Started.

Hope this helps !

Remove access to the third party app store for SharePoint on prem farms

Remove access to the third party app store for SharePoint on prem farms

If you don't want your users to access the SharePoint App store in your on prem farm and try to add or request apps for your farm, use the below command from any of your frond-end/app server to disable the app store.

Set-SPAppStoreConfiguration -Enable $false

SQL account permission sync issue on Always On

SQL account creation process is slightly different for SQL servers which are on always on availability group. The SQL account permissions won't sync properly if the SID of the accounts are not same in primary and secondary SQL server. 

Since the SQL account created in the primary SQL server cannot sync the permission properly in secondary server, after the fail over (when the secondary sever will become primary and vice versa) the account will have permission issue and cannot be used anymore to login. To avoid this issue, either 1) we should create the accounts in primary and secondary server with same SID, or 2) if the accounts are already created, delete/drop the account in the secondary SQL server and have the account recreated using same SID (this is not recommended if the account has many database mappings, it will complicate things).

Create a SQL account in primary and secondary SQL server

- Login to the primary SQL server with admin credential and run the below -

  Use [master]

  GO

  CREATE LOGIN [SQL_Login_Account_Name]  

  WITH PASSWORD = N 'Account_Password',

   DEFAULT_DATABASE=[master]

   GO

- Provide privilege to this account

- The account will not replicate automatically to the secondary SQL server. To have this account available in the secondary SQL server, we will have to re-create it in secondary. Before we do that, we need the SID of the account. Run the below to get the SID.

Select name, sid FROM sys.server_principals WHERE name = 'SQL_Login_Account_Name'

- Login to the secondary SQL server and run the below - 

   

  CREATE LOGIN [SQL_Login_Account_Name]

  WITH PASSWORD=N 'Account_Password',

  SID = SID_OF_THE_ACCOUNT_FROM_PRIMARY_SQL,

  DEFAULT_DATABASE=[master]

  GO

- Provide same privilege as given in primary 

- Go back to the primary SQL server and provide DB access to this account. The new user account will be automatically replicate in secondary SQL server with same permission.

If the accounts are already created in primary and secondary SQL server then the steps will remain same, except - 

1) Drop the account from the secondary sql server

2) Get the SID of the account from the primary sql server

3) Recreate the account in secondary sql server using the same SID

GUI doesn't support creation of accounts using same SID, hence this can be achieved only using TSQL.

SQL Server 2014 - Always on availability - Move MDF files

SQL Server 2014 - Always on availability - Move MDF files

The SQL Servers with always on availability allows you to have fail over options for databases. In an environment where you have always on availability, it requires that we remove the DB from the always on availability before we move the MDF files from one drive to another. 

In this post I am going to write about how to move the MDF files where always on availability is enabled and at the next half I will explain how to add the same DB in always on availability. So, before we start, it is expected that you have the knowledge of primary and secondary SQL server.

Move MDF Files

•          Login to the primary SQL server, expand Always On Availability
•          Select Availability Databases > Press F7
•          The object explorer window displays all DBs
•          Select the DB/s which you want to remove from Availability group and right click to "Remove Database from Availability Group"

            

•  After the DB is removed from availability, Detach the DB. Right Click on the DB and select Tasks > Detach
•  Login to Secondary SQL server
•  Remove the DB from the always on availability (refer the steps above)
•  Delete the DB/s from the secondary SQL server. Right click on the DB > click Delete > Select close all connections > click Delete
•  Copy the MDF files from source to target destination (ex. Disk2 to Disk1)
•   Login to Primary SQL Server
•  Right click on Databases > Attach > Add > Select the MDF file > click OK
• After the DB is attached we will work to add the DB in always on availability group of the primary and secondary server.