Thursday, June 25, 2009

The unequivocal joy of sharepoint and one way trusted forests

Sharepoint is one of those products that's great once it's installed and configured. The configuration of Sharepoint, however, remains a real pain...

Today's challenge was setting up a WSS 3.0 server in the testing lab. The testing lab has a separate AD forest that only has a one-way trust to the production forest. The requirement was to have the WSS 3.0 server be part of the LABTEST domain AND be able to add users from both PROD and LABTEST to the application. Now that seems simple enough since the server already sees both domains as evidenced by the logon drop down box showing both domains. However, as I found out that doesn't mean that the web app will see both as well...

Finding the right command to run was a relatively easy google search which sent me to technet. Getting the syntax right and figuring out how to use the command correctly, now that was the fun part. With the assistance of these two blogs I got it to work:

First, in several discussion groups I got differing answers over whether or not the Sharepoint Application Pool Identity needed to be set to "Network Service" or as a domain user account in the domain (in my case, the LAB domain). I used a domain user account myself but had to make changes to the DCOM because my pool wouldn't start. (Component Services - Computers -> My Computer -> COM+ Applications -> DCOM CONFIG -> IIS WAMREG -> Properties -> Security Tab -> Edit Launch and Activation and just give the domain user permissions).

Next it's time to go to a command prompt and go to C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN . Now don't do what I did and think that just because you don't have a full web farm that you can skip the first instruction

stsadm.exe -o setapppassword -password SomeRandomPassword

Literally, it doesn't matter what is set to, as long as it's the same on all your front end servers. Even one lonely standalone installation...

The second command is a bit on the long side. The full syntax I ran (names and passwords have been changed for security purposes).

stsadm.exe -o setproperty -url http://WSSVM1 -pn "peoplepicker-searchadforests" -pv "forest:AD.PROD.COM,TrustUser,3t9sz9$b20pz;forest:LAB.LOCAL;domain:AD.PROD.COM,TrustUser,3t9sz9$b20pz;domain:LAB.LOCAL"

Where AD.PROD.COM is the FQDN of my forest and root domain and LAB.LOCAL is the FQDN of the forest and root domain. (keep in mind LAB.LOCAL is the domain that the WSS server is joined to. You'll notice that I had to use a domain user account in the Trusted domain in order to be able to search it since it's only a 1 way trust. Also, while digging I found on one of the forums that you DO need to include the domain the server is joined to as well as the domain you want to add to the search. I'm not really sure if it's necessary to include both the forest: and domain: for each but it works this way so I'm sticking to this method.

On a related note, there's also an alternative way to set this up that involves setting up shadowed, non-login accounts in the resource domain that map to the real users in the production domain. It's a bit more than I needed for this project but you might find it useful.

Monday, June 8, 2009

vmrun - the grown up pain in the b** replacement for vmware-cmd

Back in the VMWare Server 1.x days stopping and starting up VMs from the command line was easy with 'vmware-cmd'. Now with Version 2.0 on my win2k3 boxes, I was forced to learn how to use the replacement - VMRUN.

I do understand that those who use the 'real' VMWARE products - ESX, vSphere, etc are quite used to using VMRUN. But if you're used to the old easy way and you're still stuck on the free versions, it's a bit tricky to get to work.

1. First off, you'll want to make sure your %PATH% variable is updated for the path to the vmrun command. ("C:\Program Files (x86)\VMware\VMware Server" on my x64 box)

2. Now open a command prompt and enter in vmrun list. This will show you a listing similar to this:

Total running VMs: 5
[standard] MYWEB2B/Win2k3R2STD_vmsrv2.0.vmx

where [standard] is the name of the default datastore in VMWare 2.x, MYWEB2B is the immediate folder under that in the file system, and then you have the filename. IT IS CASE SENSITIVE. The whole @#$% thing. If you mess that up, it will just tell you that "The virtual machine cannot be found".

3. Now that we know how to reference the vm files properly, now we need to specify the -T, -h, -u, and -p parameters. For some unknown reason, they don't appear to have a 'just run it as the server I'm sitting on and as the users I'm running this as' setting'.
Since you're using VMWare Server 2.0, you'll use -T server -h https://YourServerNameOrIP:8333/sdk (yes, it needs the sdk at the end)
and then provide a username/password (-u,-p) that is part of the administrators group on the host machine. (or if you've setup custom permissions in vmware, use one of those).

At this point, we should be able to construct this command to stop a VM gracefully:

vmrun -T server -h https://MyVMHostServer:8333/sdk -u vmadmin -p thepassword stop "[standard] MYWEB2B/Win2k3R2STD_vmsrv2.0.vmx" soft

You'll note that I introduced the 'stop' and 'soft' parameters. I'll give you three guesses what 'stop' does. The shutdown type option 'soft' will run the shutdown scripts for you for the VM to gracefully power it down. If you wanted to drop it uncleanly, just use 'hard' instead.

4. To Start it back up:
vmrun -T server -h https://MyVMHostServer:8333/sdk -u vmadmin -p thepassword start "[standard] MYWEB2B/Win2k3R2STD_vmsrv2.0.vmx"

Now combine this will some old style batch files and robocopy or xcopy and you've got a cheap way to make VM backups using Task Scheduler.

Note 1: Sometimes it just doesn't like netbios names.

Additional References:
VMRUN reference:

Tips and Tricks for vmware server 2.0: