2

Our Domain Controller and DNS Server is on the same machine as SharePoint.

We want to provision a new machine with the Domain Controller (and promote it) and the DNS Server whilst leaving SharePoint where it is.

Will SharePoint have any issues with that? Is there anything in SharePoint that needs to be configured to accompany the changes?

Now, the domain name will stay the same, but the ip address will change. And SharePoint is remaining on the server - it won't be moved.

2 Answers 2

1

This is big risk, SharePoint always upset from these kind of activities as per my experience.are you going to change the domain name as well or not? in theory if nothing going to change all the accounts and DNS remain same, you will be ok. I would recommend to stop the SharePoint during this process so no corruption happen and also Please take the backup of all your SharePoint Content Database & customization, in case of failure you can recover

But

As your DC and SharePoint on the same server, I believe you don't have too much data(size wise). I highly recommend the rebuild the SharePoint

  • Backup all content databases, all customization, note down the AAM settings
  • Uninstall SharePoint
  • setup new DC
  • Reinstall SharePoint
  • Restore content databases
5
  • Thanks for your support; I really appreciate experienced answers. You say to rebuild sharepoint, but I don't need to move sharepoint at all, just the DNS server and the DC. The domain will stay the same, but the ip address will change. For the backup, a full farm-backup should do, right?
    – bgmCoder
    Jul 19, 2014 at 3:15
  • I need to change the server's ip address first before I move the DC and DNS - that shouldn't be any problem for Sharepoint, right?
    – bgmCoder
    Jul 19, 2014 at 3:21
  • that is big risk, take the sharepoint backup 1st, i wuld do sharepoint backup as well as content database backup(just be save). I would shut down the sharepoint before changing the Ip address so that SharePoint will not upset....Usually sharePoint check the DNS/NetBios name.
    – Waqas Sarwar MVP
    Jul 19, 2014 at 3:25
  • So take full farm backup & sql backup of content Databases. Shut down the SharePoint and perform your stuff. Once everything completed now start the SharePoint
    – Waqas Sarwar MVP
    Jul 19, 2014 at 3:25
  • Well, I changed the ipaddress and there were no issues. Once I move the domain controller, I'll mark the thread solved. Thanks for your help.
    – bgmCoder
    Jul 21, 2014 at 20:41
1

Well, I did it. I moved the domain controller.

When we started out there was only one server, so we used it for everything: file-sharing, Active Directory, DNS and Sharepoint.

Later we expanded and wanted to separate the Domain Controller and DNS server from the webserver.

First we set up Active Directory on the new machine and then promoted it to Domain Controller so that there were two on the network - the original one (on the machine with SP) and the new one. We also configured DNS on the new machine also.

Then we set the DNS settings on the old server to use the new one for DNS instead of itself. Then we disable the DNS on the old server.

Then we went through the steps (there are a lot of them, and you don't really want to miss one) of making the old server use the other server as the authority for Active Directory. Then we disable the AD controller on the old server.

We took the precaution to shut down the sharepoint services whilst we did this. Finally we rebooted the server.

In the end, Sharepoint worked, but it had issues with the various service and application pool accounts.

Here are the problems that result

A domain controller does not have "local" accounts, and in fact, you can't even access the "Local Users and Groups" mmc console on a domain controller. In Active Directory, the "Local Users and Groups" are replaced with the Active Directory "Built-In" OU.

When you demote a machine from a domain controller to a regular server, all the "Built-in" Active Directory accounts that were on that machine which used to function as domain accounts get lost. I'm not exactly sure what happens, but I do know that those accounts do not get converted into local accounts. This means that whatever service accounts and application pool accounts you were running with "Built-In" accounts now no longer have rights on the local machine! So Sharepoint just won't work until you fix this.

Another problem is this: The domain accounts you were using for Sharepoint services and application pools no longer have local rights on the server! That means that those accounts no longer have rights to do anything on the server.

Here is how to fix those problems

To fix this account-mismatch problem, you have to create local groups on the server and give them access to perform local operations. Then you have to take the domain accounts that you are going to use for the service and application pools and add them to those local groups.

In particular you must not forget to add directory replication rights to a group in which you want to include the UPS service.

You also want to create a group called *SharepointBatch" for accounts that need Batch/Service Logon rights, such as the UPS service and Search Service.

Another thing that happens is that you have to go through SCA's Managed Services and reset all the passwords. I also had to reset the passwords in IIS for each application pool.

One clue that you have a password mismatch is that when you try do access a page that runs a particular service, in IIS you will see that the application pool has crashed as soon as you accessed the page.

Now, I never did get all the account permissions lined out completely. I still have accounts in the local administrator's group that shouldn't be there.

What I recommend is that until you figure out what accounts should have what rights, create a general group for sharepoint admin rights and put everything in it until you can go through them one by one and assign them proper permissions. At least you'll have a working portal in the mean time.

Here are a few good links to sites with list of permissions requirements for accounts.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.