Geek projects, tidbits and things I'm working on at the moment…

I’m getting ready to migrate our AD servers to a virtual environment and one of the things that can get messed up is the AD servers’ time. Also, I’m joining some non Windows systems to the Windows domain which might encounter some time sync issues since they aren’t currently configured to use the domain’s NTP server (easy fix I know but I’m saving that for another post!)

Short story long, your AD server typically uses its’ CMOS time versus an external NTP server which is all fine and good so long as A) it’s a real hardware server not a virtualized one and B) No other servers in your infrastructure use other NTP servers (ie. Linux server ‘A’ isn’t using tick.usno.navy.mil which will have a different time then your main AD server which is going off of it’s CMOS clock!)

So, I did some searching on the interwebs and stumbled upon a couple of useful links on how to modify your registry on your AD server so it:

A) Uses an external time source versus the CMOS time & date.

B) Has a number of servers to attempt time updates from (use spaces to delimit servers! and don’t forget to append “,0x1” at the end if you’re using a FQDN versus an IP Address!)

C)…I forget C!

Anyhow, here’s some links I wrangled up.

http://support.microsoft.com/kb/816042#method2

http://www.windowsnetworking.com/articles_tutorials/configuring-windows-time-service.html

 http://www.sole.dk/how-to-configure-your-virtual-domain-controllers-and-avoid-simple-mistakes-with-resulting-big-problems/ (this one was most helpful!)

Just finished installing a fresh server with SharePoint 2010 Enterprise so an employee could look at the business intelligence dashboard stuff. While doing the install, I received an error about the MS Sync Framework 1.0 failing which caused the whole thing to screech to a halt. It would appear that I installed the .NET 4.0 stuff via Windows Updates which caused the .NET 1.0 Sync Framework to puke on me. Thankfully, MS had a hotfix for that which resolved my issue. You can see the Microsoft Sync Framework Runtime v1.0 listed on SharePoint 2010’s HW & SW requirements list.

http://support.microsoft.com/kb/962229

After I manually installed the hotfix, the “Install software prerequisites” continued and I had the SharePoint 2010 site up and running before lunch!

At work, we’ve installed SharePoint servers a couple of times. A reoccurring issue, is a permissions issue that appears in the event logs as Event ID: 10016 or 10017 but doesn’t seem to effect SharePoint performance. We just recently installed SharePoint 2010 and I decided to chase these errors down since it’s annoying and fills up the log files. Seems the local domain account you create to run specific SharePoint services during the initial installation don’t have specific permissions for local activation.


The machine-default permission settings do not grant Local Activation permission for the COM Server application with CLSID
{000C101C-0000-0000-C000-000000000046}
and APPID
{000C101C-0000-0000-C000-000000000046}
to the user SOMEDOMAIN\SOMEUSERACCOUNT_SVC SID (S-1-5-21-BLAHBLAHBALHBLAH) from address LocalHost (Using LRPC). This security permission can be modified using the Component Services administrative tool.


So if you run off to the Component Services, find the offending CLSID object and right click->properties, hit the Security tab to allow this account to run this DCOM object it’s greyed out!

You’ve apparently got to find it in the registry first (should be “Computer\HKEY_CLASSES_ROOT\AppID\YOUR_CLASSID_HERE.”)

Once found, right click the key in the left pane and goto permissions. From there, you’ll want to take ownership of the registry object from the Trusted Installer which will allow you, the admin, to change its’ security permissions w/in the dcomcnfg application.

Now that’s done, open up the “DCOM Config” node of the local computer, find your AppID GUID, right click and select properties. Now select the Security tab and change your Launch & Activation Permissions for your domain account that’s generating your error.

As always, here’s some links to explain:

http://social.msdn.microsoft.com/Forums/en/tfsadmin/thread/883b5f1c-1718-4b9a-a6c8-bf32c5d4d6d2

http://support.microsoft.com/kb/920783

http://www.wictorwilen.se/Post/Fix-the-SharePoint-DCOM-10016-error-on-Windows-Server-2008-R2.aspx

So I’m playing around w/ a SAN for home use. We’ve virtualized about 80% of our infrastructure at work but most of our VM hosts are standalone with local storage only. So, I’m spending a lot of time at home recently building a SAN on OpenSUSE 11.3 with high hopes of getting iSCSI to play nice. Part of this equation is getting another box to run vCenter Server which will need access to the iSCSI LUNs the VM hosts see.

Hence the title. Windows has a utility called Diskpart.exe which will allow you to turn off auto mount BEFORE you connect your Windows’ iSCSI initiator to your iSCSI target.

Open up a command prompt and type:

C:\Users\yournamehere>diskpart


Once you’re in the diskpart tool, type ‘automount’.

DISKPART> automount
Automatic mounting of new volumes enabled.

Then finally, ‘automount disable’.


DISKPART> automount disable
Automatic mounting of new volumes disabled.

This will keep your OS from trying to mount your iSCSI volume and mess with your VMFS partition!

Keep in mind, this means any new volumes your system sees will need to be mounted manually w/in the disk partitioning tool.

While you’re in there, type just a ‘?’ and see the whole list of commands you can play with. See the Microsoft KB article below for a more thorough introduction!

http://support.microsoft.com/kb/300415