VMware—At Your Service!
Finally! Chris Wolf, you cannot believe how long I've been looking for information about how to run my virtual machines (VMs) as a service and do exactly what you talked about in "VMware—At Your Service!" (June 2004, InstantDoc ID 42607): run a domain controller (DC) in a VM and have the host log on to it. "VMware—At Your Service!" is a great article. Thanks!
P.S. On another topic, I had a hard time finding out how to turn off the PC beep sound for a VMware session. You can add mks.nobeep = "TRUE" to the .vmx file to do
The method Chris describes in "VMware—At Your Service!" is a great trick. We used a similar method and installed the AutoExNT service, another resource kit utility that lets you run an autoexec.bat file as the local system account without logging in under a user session. You can use the same command lines Chris uses to run your VMware machines without having to install them as services.
Conquer the ADSI Edit Built-In Limit
In "Conquer Active Directory's Built-In Limits" (June 2004, InstantDoc ID 42605), Tony Murray-Smith states that the default Active Directory (AD) search buffer size can cause problems. He says that changing the registry setting works well for the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in, but that the setting seems to have no effect on the MMC ADSI Edit snap-in.
However, increasing the buffer size in the ADSI Edit snap-in is possible. Highlight the domain node and select View, Filter. The default maximum size is 10,000, but you can increase this number.
Geographically Distributed Clustering
I read Ed Roth's "Geographically Distributed Clustering" (June 2002, InstantDoc ID 24890), and I have a question. We're looking into building a Microsoft SQL Server cluster with Windows Server 2003. I'll use the same make and model server, but I'm wondering whether I can cut out a couple of processors to save money.
I'm not a SQL Server specialist, but I know people who work with SQL Server for a living. Here's what my friendly DBA says about tying SQL Server to a single processor.
"You can indeed save money on SQL Server licenses by restricting SQL Server to fewer processors than a machine has. According to our Microsoft representative, you don't have to physically disable the processors in a multiprocessor system, but you do need to alter the properties of the server in SQL Server Enterprise Manager to bind the SQL Server instance to only the processors for which you have SQL Server licenses. You must still purchase one processor license for Windows for each processor the OS can see (if that's the license model you're using). Also, note that the newer hyperthreading processors appear as two processors to the OS, but only one license is required per physical processor whether you're talking Windows or SQL Server.
For example, we have two physical processors hyperthreading SQL Server running Windows 2003. We have two one-processor licenses for the OS and a one-processor license for SQL Server. In Enterprise Manager, the SQL Server instance is restricted to two of the four processors (equaling one hyperthreaded physical processor)."