p2p.wrox.com Forums

p2p.wrox.com Forums (http://p2p.wrox.com/index.php)
-   BOOK: Professional SharePoint 2007 Development ISBN: 978-0-470-11756-9 (http://p2p.wrox.com/forumdisplay.php?f=341)
-   -   Chapter 2 - Using copies of virtual machine fails (http://p2p.wrox.com/showthread.php?t=69213)

Jvillalobos July 7th, 2008 04:27 PM

Chapter 2 - Using copies of virtual machine fails
I have faithfully followed the instructions in the chapter to create a base virtual server VS2003BASE. However, instead of installing AD and DNS in the virtual server, I connected the VM to a separate physical server containing AD and DNS. As suggested, I made a copy of the base machine, placed it in a separate folder, and used it to do development work. That initial copy works well.

Now the problem: If I make another copy of the base server to work on a different project and try to log in to the network, the log in fails with the message:

"Windows cannot connect to the domain, either because the domain controller is down or otherwise unavailable ..."

Logging in to virtual machine using the local account to check the Event Viewer, I find the following System Error message:
This computer could not authenticate with \\versailles.SierraFS.local, a Windows domain controller for domain SIERRAFS, and therefore this computer might deny logon requests. This inability to authenticate might be [u]caused by another computer on the same network using the same name </u>or the password for this computer account is not recognized. If this message appears again, contact your system administrator.. "

It is clear that the server has trouble authenticating more than one virtual machine with the same computer name. ([u]Notice that here I am running one virtual machine at a time</u>).

But if I change the computer name, SQL Server and SharePoint no longer work.

I have tried to reset the machine account in the server by moving the VM membership from network to workgroup and back to network, but the results are spotty. It worked a couple of times, but on subsequent times SharePoint ceased to work. I reran the SharePoint configuration Wizard without error, but both Central Administration pages and any of the SharePoint sites display empty pages.

Is there a meaningful solution to this problem? I cannot risk moving into separate virtual machines if these decide to stop working midway to a critical project conclusion. Thanks.

erobillard July 8th, 2008 05:10 PM


The problem is that if using a the same domain controller ("DC" aka your primary AD server) from several machines, the DC will cache the SID and machine name of each machine that connects to it, and store Secure Channel tokens on both the DC and each machine. These are valid for 30 days before being recreated, and old tokens are remembered to ensure continuity; much the same as old passwords are cached so you can't re-use them when certain AD policies are in place. This whole process exists so you can't spoof a machine in a Windows network, which is what you're doing, albeit on purpose and with good intentions.

First a non-solution, then two solutions. You may be able to fix this for 30 days by copying your SharePoint image after the initial connection to AD rather than before. But eventually the Secure Channel token requires renewal and at that point, you're out of luck.

The real solution: this is a case where unique SIDs and machine names will cause some configuration pain but will solve the problem. What each SharePoint server needs is a unique identifier as described on pp. 41-44 for building farms.

Where the pain comes is that the SID and new machine name are assigned after Windows Server 2003 is installed, but before SharePoint. If you're wishing that part of the install could be scripted easily, that's a hope for Windows Server 2008.

Speaking of 2008, it's said that server name changes on Vista Server are painless (see the last paragraph of http://bobfox.securespsite.com/FoxBl...ost.aspx?ID=45) and SIDs aren't used in SharePoint's configuration database though they do tend to "grow roots" in the registry.

The other solution: Perhaps you can clone your AD server and pair each with a SharePoint server to spin up isolated development farms. This would eliminate the token caching issue, because each AD server is paired with a SharePoint server. For me this would be less effort to install AD and DNS on a base image for cloning than SharePoint plus my development tools. If you still need a central DC, your virtual machines could simply be on a different domain with a trust to your "physical" domain.

If you choose that route, you should only need a minimal virtual hard drive (1 to 4 GB?) and 256 MB RAM (or less) to run an effective DC with AD and optionally DNS. Remember to remove unused Windows components and services. Really low memory will mainly affect this server's boot time, but once running AD is extremely efficient.

Hope this helps,

All times are GMT -4. The time now is 09:23 PM.

Powered by vBulletin®
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
© 2013 John Wiley & Sons, Inc.