How to reset Directory Services Restore Mode Password (DSRM)

When a Windows Server machine is prompted to a domain controller (DC), the Directory Services Restore Mode (DSRM) password is created for the local administrator account. This password will be used only when booting into the recovery console or Directory Services Restore Mode. If you forget the DSRM password, you can’t use the recovery console nor restore the Active Directory (AD) database.

Change or Reset the DSRM Administrator Password

If you can log on domain controller using the domain administrator account, you can use the NT Directory Services utility (Ntdsutil.exe) to change the DSRM administrator password. To do so, follow these steps:

  1. Log on to the domain controller using an account with administrative rights.
  2. Go to Start | Run, type cmd, and press [Enter].
  3. At the command prompt, type cd %SystemRoot%\System32,and press [Enter].
  4. Type ntdsutil, and press [Enter].
  5. Type set dsrm password, and press [Enter].
  6. At the DSRM command prompt, you can reset the password for either the server on which you’re working or for another server. For the former, type reset password on server null, and enter the new password when prompted. (No characters will appear when you type the password.)
    To reset the password for another server, type reset password on server <servername> (where <servername> is the DNS name for the server in question), and enter the new password when prompted. (No characters will appear when you type the password.)
  7. At the DSRM command prompt, type q to exit.
  8. At the Ntdsutil command prompt, type q to exit the utility and return to the command prompt.

Its always a good practice to store the password in a password manager or similar safe place. 

Configure SharePoint 2016 (Part 6)

Configure SharePoint 2016 (Part 6)

In the last post, we created service accounts and configured claims to windows token service. In this post, we will run products and configuration wizard and complete SharePoint 2016 configuration.

Before we start running SharePoint 2016 Product & Configuration wizard, we need to make sure that your SharePoint Application Server can talk to SQL Server. The default firewall settings may not allow SharePoint Server to Connect to SQL Server over port 1433. You can run the following script to open up the required ports for accessing SQL Server.

@echo ========= SQL Server Ports ===================

@echo Enabling SQLServer default instance port 1433

netsh firewall set portopening TCP 1433 “SQLServer”

@echo Enabling Dedicated Admin Connection port 1434

netsh firewall set portopening TCP 1434 “SQL Admin Connection”

@echo Enabling conventional SQL Server Service Broker port 4022

netsh firewall set portopening TCP 4022 “SQL Service Broker”

@echo Enabling Transact-SQL Debugger/RPC port 135

netsh firewall set portopening TCP 135 “SQL Debugger/RPC”

@echo ========= Analysis Services Ports ==============

@echo Enabling SSAS Default Instance port 2383

netsh firewall set portopening TCP 2383 “Analysis Services”

@echo Enabling SQL Server Browser Service port 2382

netsh firewall set portopening TCP 2382 “SQL Browser”

@echo ========= Misc Applications ==============

@echo Enabling HTTP port 80

netsh firewall set portopening TCP 80 “HTTP”

@echo Enabling SSL port 443

netsh firewall set portopening TCP 443 “SSL”

@echo Enabling port for SQL Server Browser Service’s ‘Browse’ Button

netsh firewall set portopening UDP 1434 “SQL Browser”

@echo Allowing multicast broadcast response on UDP (Browser Service Enumerations OK)

netsh firewall set multicastbroadcastresponse ENABLE

Once the connection to SQL Server is configured, you can start SharePoint 2016 Products and Configuration from the Start Menu. You will see the following screen. Click next.

Figure 1

You will see a message about IIS services, click Yes and Next.

Figure 2

You will have an option to connect to an existing server farm or create a new server farm. Since this is the first SharePoint server in the farm, we will click on option Create a new server farm. Click Next.

Figure 3

Specify database settings on this screen. Click Next.

Figure 4

Specify a Passphrase. And make sure the Passphrase is stored in a safe and retrievable place as we would need this for various activities like adding more servers to the farm, etc.

Figure 5

This is new in SharePoint 2016. You can specify a predefined role for the server you are configuring. For this lab, we will configure single server farm. For an elaborated description of each role, refer to my previous post “What’s new in SharePoint 2016 (and what’s deprecated)“. Click Next.

Figure 6

Review the parameters selected and entered and click Next.

Figure 7

You should see the configuration in progress. Creating the configuration database may take most of the time, everything else should complete relatively fast.

Figure 8

Once the configuration is successful, you will see the following completion message. Click Finish. This should start Central Administration screen and a wizard to configure all Service Applications. Click cancel, we will configure these service applications manually.

Figure 9

Navigate to Central Administration à Security à Configured Managed Service Accounts and add the service accounts configured. You should be able to see the following once the Managed Accounts are configured.

Figure 10

Navigate to Central Administration à Manage Service Applications. You should be able to see the two default service applications.

Figure 11

Once this step is completed, it’s good to review the following.

  1. Central Administration à Security à Manage the farm administrators group and review that you have all the required accounts (E.g. Admins, etc) added in there.
  2. You are able to access SharePoint 2016 PowerShell.

In my next blog post, I will show you how to create and configure service applications manually along with their PowerShell scripts. Till then, keep watching this space.

Configure SharePoint 2016 Service Accounts (Part 5)

In part 4, I showed you how to install SharePoint 2016 and we stopped at running Products & Configuration wizard. And before we complete our configuration, we need to ensure the following service accounts are created for using against various service applications. Some of the best practices of creating SharePoint Service Accounts are

  1. Use Password Never Expires – All service accounts should be set to “Password never expires” in Active Directory because if they expire in future after installation of SP2016 it would be an issue for the continued operations of SharePoint.
  2. Place all Service Accounts in single OU – This placement allows system administrators to easily locate and view service accounts, group them in one Active Directory OU.
  3. Strictly Avoid Special Characters – Do not use service account names that contain anything other than _.
#

Account

Description

Access Level

1 svcSPSetup The Setup user account is used to

a. Install SharePoint

b. Run the following: Setup SharePoint Products Configuration Wizard

  1. Member of the Administrators group on each server on which SharePoint Setup is run.
  2. SQL Server login on the computer that runs SQL Server.
  3. Member of the following SQL Server roles:
    1. securityadmin fixed server role
    2. dbcreator fixed server role
  4. If you run Windows PowerShell cmdlets that affect a database, this account must be a member of the db_owner fixed database role for the database.
2 svcSPFarm The Server farm account or database access account. The server farm account is used to configure and manage the server farm. And acts as the application pool identity for the SharePoint Central Administration Web site.
  1. Additional permissions are automatically granted for the server farm account on Web servers and application servers that are joined to a server farm.
  2. The server farm account is automatically added as a SQL Server login on the computer that runs SQL Server. The account is added to the following SQL Server security roles:
    1. dbcreator fixed server role
    2. securityadmin fixed server role
    3. db_owner fixed database role

for all SharePoint databases in the server farm

3 svcSPApp This account is used for Content Web Application. None unless using Office Web Apps. Then must give access to content databases manually.
4 svcSPService This account is used for Service Application Pool. Must be a member of the Farm Administrators group.
5 svcSPMySite This account is used for My Site Application Pool. This account must not be a member of the Administrators group on any computer in the server farm.
6 svcSPSearch
7 svcSPCrawl This account is used for default content access account for Search Crawling
  1. The default content access account must be a domain user account that has read access to external or secure content sources that you want to crawl by using this account.
  2. For SharePoint Server sites that are not part of the server farm, you have to explicitly grant this account full read permissions to the web applications that host the sites.
  3. This account must not be a member of the Farm Administrators group.
8 svcSPWorkFlow This account is used for SharePoint Workflow Manager Service
9 svcSPC2WTS This account is used for Claims to Windows Token Service Must be a member of the Farm Administrators group.
10 svcSPUPSync User Profile Synchronization Connection Service Account Member of the Administrators group on each server on which SharePoint Setup is run.
11 svcSPCacheSuperUsr Cache Super User
  • The object cache accounts are user accounts that are given FullControl and FullRead privileges on WebApplications so items can be cached by ASP.Net to improve performance.
  • These accounts should not have any special Active Directory privileges other than Domain User membership
12 svcSPCacheSuperRdr Cache Super Reader
  1. The object cache accounts are user accounts that are given FullControl and FullRead privileges on WebApplications so items can be cached by ASP.Net to improve performance.
  2. These accounts should not have any special Active Directory privileges other than Domain User membership
13 svcSPSSRS SQL Server Reporting Services Service Application Account
14 svcSPPPS Performance Point Services Service Application Account

In addition to the above configuration, there are some special configuration changes required for claims to windows token service account to be done on each SharePoint server. The Claims to Windows Token Service (C2WTS) is a component of the Windows Identity Foundation (WIF) which is responsible for converting user claim tokens to windows tokens. Excel services uses the C2WTS to convert the user’s claims token into a windows token when the services needs to delegate credentials to a back-end system which uses Integrated Windows authentication.

Each SharePoint service application must run the C2WTS locally. The C2WTS does not open any ports and cannot be accessed by a remote caller. Further, the C2WTS service configuration file must be configured to specifically trust the local calling client identity

As a best practice you should run the C2WTS using a dedicated service account and not as Local System (the default configuration). But Local System will work if you configure the Kerberos constrained delegation to use the machine name account. The C2WTS service account requires special local permissions on each server the service runs on so be sure to configure these permissions each time the service is started on a server. Optimally you should configure the service account’s permissions on the local server before starting the C2WTS, but if done after the fact you can restart the C2WTS from the Windows services management console (services.msc).

To start the C2WTS using Domain Account

  1. Add an arbitrary Service Principal Name (SPN) to the service account to expose the delegation options for this account in Active Directory Users and Computers. The SPN can be any format because we do not authenticate to the C2WTS using Kerberos authentication. It is recommended to not use an HTTP SPN to avoid potentially creating duplicate SPNs in your environment. In our example, we will have registered ‘SP/C2WTS’ to the ‘infrafusion\svcspC2WTS’ using the following command:

    SetSPN -S SP/C2WTS infrafusion\svcspC2WTS

  2. Configure Kerberos constrained delegation on the C2WTS services account. In his scenario we will delegate credentials to the SQL service running with the ‘MSSQLSVC/NACDB02.infrafusion.xyz:1433’ service principal name.

    Key configuration options on the delegation tab are the following:

    a) Select “Trust this user for delegation to specified services only”

    b) Select “Use any authentication protocol”

  3. Next, configure the required local server permissions that the C2WTS requires. You will need to configure these permissions on each server the C2WTS runs on. In our example this is VMSP10APP01. Log onto the server and give the C2WTS the following permissions:
    1. Add the service account to the local Administrators Groups.
    2. In local security policy (secpol.msc) under user rights assignment give the service account the following permissions:
      1. Act as part of the operating system
      2. Impersonate a client after authentication
      3. Log on as a service

This will prepare Claims to Windows Service Account to be used with SharePoint 2016 after the configuration is completed.

In this post, we configured service accounts with their appropriate access. In the next post, we will run the product & services configuration wizard and configure each Service Application to use their designated service account. Till then, keep watching this space.

Build Active Directory Domain Controller (Part 2)

Build Active Directory Domain Controller (Part 2)

In the part 1, I introduced the goal of this series along with architecture diagram of building a hybrid SharePoint 2016 farm. In this part, we shall see configuration of Active Directory Server. We are building a single domain controller running on Windows Server 2012 R2 with a static IP configured and updated till the latest windows patch.

  1. Login as a local administrator on the server.
  2. Open Server Manager and click on Manage and then Add Roles & Features.
  3. Click next as show in Figure 1 below.

Figure 1

  1. Select Role-based or feature based installation and follow the steps till figure 10 below.

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

  1. After the installation is completed, the restart the server. After server restarts, we need to promote the server to domain controller. This can be done by clicking the alert icon on top left and then click on Promote this server to domain controller (Figure 11).

Figure 11

  1. Since we are building the first domain controller in the forest, the following steps need to be meticulously followed. Click on Add a new forest and enter root domain name as infrafusion.xyz.

Figure 12

  1. Enter password and click next on the Domain Controller Options screen.

Figure 13

  1. Click next on the DNS option screen.

Figure 14

  1. Verify NetBIOS name on the Additional Options screen and click next.

Figure 15

  1. Click next on the Paths screen and click Next.

Figure 16

  1. Verify and review the selections. If you click on View Script, you should be able to see the PowerShell script for building this Active Directory and Click Next.

Figure 17

  1. Click Install after Prerequisites Check is successfully completed. You can ignore these warnings.

Figure 18

  1. After the installation is completed, the server will restart and you can enter the admin credentials for domain instead of local admin.

In this article we built an Active Directory Domain Controller. In the next article of this series, we will install SQL Server 2014 SP1. Till then keep watching this space.

Build SharePoint 2016 Environment (Part 1)

Build SharePoint 2016 Environment (Part 1)

Introduction

In this article, I am going to build from scratch a SharePoint 2016 on premise deployment. We will also configure Office 365 in this deployment and use several configurations like external DNS, Azure AD Connect, ADFS and Web Application Proxy to build this environment. The focus of this article series is to help an administrator build a SharePoint 2016 environment from ground up with Active Directory Domain Services, Active Directory Federation Services, Web Application Proxy, Azure AD Connect, Azure AD Proxy, SharePoint 2013 Application Server, SharePoint 2013 Web Front End and Office Web Apps Server. The following figure depicts our end goal. As we progress on the On Premise farm, we will design and build the Office 365 tenant as well.

Figure 1

Let’s look at hardware and software requirements for building each of these server.

Workload

OS

RAM

CPU

Storage

SharePoint Application Server Windows Server 2012 R2 16 GB 64-bit 4 Core 80 GB
SharePoint Web Front End Windows Server 2012 R2 12 GB 64-bit 4 Core 80 GB
SQL Server 2014 Windows Server 2012 R2 12 GB 64-bit 4 Core 80 GB 100GB
Active Directory Domain Services Windows Server 2012 R2 8 GB 64-bit 4 Core 80 GB

Other necessary pre requisites

  1. Registered domain name (E.g. infrafusion.xyz) – In this tutorial, we shall not use non-routable domain name but a routable domain name infrafusion.xyz to depict real life enterprise scenario. And at the same time, a domain name registered with internet authority will be required to validate on Office 365 tenant and use for several cloud workloads.
  2. Office 365 Tenant – You can use existing Office 365 tenant if you have global admin access to but I would recommend against using a production Office 365 tenant. You can register for a trial Office 365 tenant. If you are an enterprise in United States and would like me to support your Office 365 trial needs, you can register for an Office 365 tenant using this link. For other regions, if you need supported trial, reach out to me at ravee@gokulgaandhi.com and I would be happy to help you with your Office 365 trial configuration.

This concludes part 1 of the Build SharePoint 2016 series. In Part 2, we shall build our first Active Directory Server and all the required service accounts. Till then stay tuned on the blog.