Our company decided to organize the environment for development and testing for SharePoint 2016.

At first I thought to clone a half of VMs of servers of a farm of sharepoint in our normal test vlan with RODC and just to rename servers. But I was told what so won't work. Then we decided to create the complete copy of a production environment in completely isolated vlan the only thing that this IP will change.

Сloned one of our ADC there. There in isolated vlan it now the complete copy of our productive ADC and the master of all FSMO of roles.

Сloned all servers of a farm SharePoint there. Now we have a complete copy of our productive farm of sharepoint (all names of servers are identical to original) except for IP addresses. on local ADC I of course corrected appropriate dns of record. The SQL server works normally all bases are available. But sharepoint for some reason doesn't work!

Prompt in what there can be a reason (can machines were copied and joined in a missequence or something else). generally such scenario can work? I know that the simplest option for the organization of the test environment it "new installation" but can somebody so already tried and it worked?


1 Answer 1


If SharePoint doesn't work, because it should, there are a few things to check:

  • Are all your servers part of your test-domain, and can you sign in to SharePoint Servers using a domain account? i.e. TESTAD\SPFarm instead of .\Administrator?
  • Can you access SQL Server from SharePoint Servers? Either you install SQL Server Management Studio Client and access your SQL Server with computername\instance-id only (not FQDN).
  • Do you use SQL-Alias on your SharePoint Servers (you should) and are they pointing to the new IP-address of the SQL Server? Run cliconfg from CMD and check
  • Obviously you have pinged your Domain Controller and SQL Server from SharePoint Servers, but have you tried accessing ports as well with telnet? See TCP/IP Ports of SharePoint 2013 for reference
  • Can you access the farm using PowerShell? Running SharePoint Management Shell will tell you quickly.
  • The domain accounts your using, do they exist in your TEST-AD, or they didn't follow over to they new environment?

Still in trouble and nothing works? Try to create a new farm on one of your servers on another instance of your SQL Server, and see where that leads you.

  • 1 and 6 we cloned one of our main domain controllers that servers and accounts were copied together with it. Yes, I can sign to test SP servers using domain account from this test DC. 2-3 I will surely try 3 all servers successfully give results of nltest/query, telnet * to adcontroller * 389, telnet * SQL-alias * 1433 4 SharePoint Management Shell is launched the truth I don't know what command it is possible to enter for the test
    – user61779
    Commented Nov 12, 2016 at 21:25
  • errors in EventViewrs looks like: wfe docs.google.com/document/d/… appsrv docs.google.com/document/d/…
    – user61779
    Commented Nov 12, 2016 at 21:38
  • It's pretty clear that you have domain and/or DNS issues due to the bad username/password messages. You should instead just build a new farm from scratch and automate that build with PowerShell for something that is easy to reproduce. You'll spend less time in the short/long run.
    – user6024
    Commented Nov 13, 2016 at 4:40

Your Answer

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