SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It only takes a minute to sign up.
Sign up to join this community
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.
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
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.
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.
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.
