Since January of this year I’ve been using Facebook to stay in touch with friends, colleagues, and other folks I don’t see often. There’s something to be said about seeing people’s faces every day which reminds you to stay in touch. Poke (and SuperPoke) is the greatest way to tell someone “hi” without getting into a dialog.

Since Facebook wants to make a few dollars in their effort to provide free services, they’ve initiated clandestine tactics to gather and distribute your surfing habits to others. Facebook’s Beacon software isn’t terribly popular for this reason but there are ways to keep it quiet.

wikiHow describes the proper way to disable Beacon in Facebook’s security settings as well as the BlockSite add-on for Firefox. Although the article doesn’t mention this you can use the BlockSite add-on in Flock (which, like Firefox, is based on Mozilla.

Manas Tungare describes how to filter out Beacon in the Mac version of Safari. I haven’t installed PithHelmet to test because it appears only in beta status for Safari 3 (which ships with Leopard).

The tedium of a Windows user account without Administrator privilege is almost unbearable. Installing software and other updates would require logout/in as Administrator and, while not difficult, is a hassle.

Microsoft introduced the RunAs command from the Command Prompt and the graphical user interface to overcome this. Right-click a program, choose Run As…, and enter your Administrator details. The application will install within your limited user account.

The trouble arises when you want to install an MSI file because they aren’t executables like SETUP.EXE. You’ll find that right-clicking an MSI from Windows Explorer only provides an Install option, not Run As. This makes it almost impossible to install the MSI from a limited user account.

I found ways to hack your Registry to enable RunAs for MSI files but there’s an easier way if you don’t mind some typing. In short, you’ll be using the command line to execute MSIEXEC using runas and referencing the MSI file. Example:

runas /u:[domain]\[user] "msiexec.exe /i [path-to-file]\[file.MSI]"

Substitute the bracketed fields as needed. If you are not connected to a Windows Server Domain you can ignore the [domain]\ text. Make sure the MSIEXEC command is enclosed in double-quotes. You may have trouble if there are space characters in your folder path or filename; try enclosing them in double-quotes or copy the MSI file to a location such as C:\TEMP to keep the path simple.

Hit Enter and you’ll be prompted to type a password (assuming Administrator) and the MSI will install as if you chose Run As… from Windows Explorer.

I thought Windows’ Distributed File System (DFS) was something with ugly hooks into Active Directory and the Registry. While it might, my recent migration of the DFS root from one server to another went smoothly. Most of the information about migrating DFS is wordy and confusing. I’ll attempt to explain the process using my client’s configuration as an example.

The Servers

Two servers with Windows Server 2003 SP1, both domain controllers. SERVERA keeps user profiles and shared data using conventional shares. SERVERB stores large amounts of project data separated into folders and residing on a SCSI-attached RAID-5 system. The DFS root share for the domain is kept on \\SERVERB\E$ in a folder (and share) called \DFSroot\Proj. A domain-wide DFS root called “Proj” points to \\SERVERB\Proj.

The Issue

The RAID system attached to SERVERB is getting long-in-the-tooth and ready for retirement. All of the project data was moved to a new HP Storage Area Network (SAN) but the DFS root was still on volume E of the old RAID. The DFS root must be moved to a different SAN volume on the same server.

The Migration

I found these links (1, 2) the most helpful to describe the process. Here’s what I did:

1. Export the current DFS links:

   dfsutil /root:\\DOMAIN\Proj /export:proj-dfs.txt

2. Remove the DFS links and root using the MMC
3. Run DFSUTIL using the /clean option as specified here
4. Run:

   net stop dfs

   then

   net start dfs

   on SERVERB

5. Delete the folder structure of the old DFS root (volume E, \DFSroot\Proj)
6. Create another folder structure for the new DFS root (volume I, \DFSroot\Proj)
7. Share the new Proj folder and assign NTFS and share permissions accordingly
8. Using the MMC, create a new domain-wide DFS root (called “Proj”) pointing to \\SERVERB\Proj
9. Import the DFS links using:

   dfsutil /root:\\DOMAIN\Proj /import:proj-dfs.txt /set

This took about 20 minutes to accomplish and was easier than I expected. The DFS root is just a “master” share which points to other shares and doesn’t touch (or harm) your data in any way. Of greatest concern is performing the export of the DFS links to save yourself a lot of typing.

The process shouldn’t be much different migrating between servers, however would include additional steps to move data and create folder shares as needed.

For the longest time I have stayed away from Windows XP feature Offline Files. Not for me, but for my clients. It’s lightly documented and there seems to be more troubles than success stories of people using it. However, one of my clients needs this feature, not a generic solution, to move seamlessly while traveling.

There are a myriad of issues to get the configuration correct, especially when using Group Policy via Active Directory, but they’ll sort themselves out. What always puzzled me was how Windows managed the synchronization of files between the client and server. Let me describe how it works.

Continue Reading »

Ever since Microsoft led the charge with Windows 95 the traditional way of software versioning using decimal numbers (i.e.: Windows 3.0, 3.1, etc.) went out the window. Microsoft felt the consumer needed an easier way to know what they were running and they supposed Windows 4.0 was too difficult to remember. It turns out this was simply marketing mumbo-jumbo because Windows 95 still carried a decimal version number of 4.00.950 and undoubtedly you’d be asked to provide this when communicating with your tech support department.

Although Microsoft abandoned the use of a model year with Windows XP it still rears it’s head in some versions of XP. Consider this screen capture of Windows XP Tablet Edition and remember that the model year was intended to avoid consumer confusion.

That’s right: Microsoft Windows XP Tablet PC Edition 2005 Version 2002 Service Pack 2.

• So which is it? Version 2002 or 2005?
• Why didn’t the Version 2005 code supercede that from Version 2002?
• What is Service Pack 2 for? Version 2002 or 2005?
• Why isn’t it called Service Pack August 6, 2004?

I’m more confused than ever thanks to someone at Microsoft deciding how product names should be presented to consumers and clearly missing the point.

You may be wondering about the decimal equivalent of Windows XP Tablet PC Edition 2005 Version 2002 Service Pack 2. Surely it’s a wicked amalgamation of decimal points and numbers. No, it’s quite simple:

Microsoft Windows XP [Version 5.1.2600]

I’m thankful Microsoft dropped the model year for Windows Vista because, clearly, it wasn’t working.