First, I need to be clear that while my comments in the original post were quite negative regarding some of its features (or lack thereof), in the year-plus that we’ve been running the miSAN D-12 in production we’ve had ZERO problems with it. We have about 24 virtual servers (over three vSphere hosts) all running from the miSAN without performance issues, and the unit has even recovered gracefully from a few power-outage situations where the UPS just couldn’t run long enough (no generator here… sigh), yet we experienced not data corruption and everything “came back” just fine. All in all I’ve been very happy with the reliability and performance of our miSAN (it did lose a power supply once, but was quickly replaced by Cybernetics).

So, fast forward to about two months ago where I saw a mailer touting the new miSAN 4.0 features. The ones that caught my eye were more IOPS (who doesn’t want better performance?) and better expandability. I called my Cybernetics rep and asked if my miSAN D-12 could be upgraded to this new-and-improved OS, and he replied that unfortunately, no, it wasn’t possible. The new OS only works with newer hardware…

…but then he went on to say something quite astonishing: That while we would typically need to ship a miSAN back for a “retrofit” upgrade to the new OS and new hardware (typically costing somewhere around $1700), they would do it for me free… with the only cost being shipping my unit to them. Say what?! I then replied that while the offer was very generous, there’s no way I could take our miSAN offline to ship it back for a week while it was upgraded. While I do have some local ESX storage, I don’t have that much! My rep responded that he would be glad to ship us a new miSAN, let us get it up and running and move our VMs to it, then ship ours back… again just for the cost of paying to ship it.

So that’s exactly what we did. We received the new miSAN D-12 (configured exactly as our original unit, but with better features and a completely different controller), took about two weeks to move our VMs to it gradually, then shipped ours back. All in all it was about $230 for this upgrade. For that I now have a SAN with significantly better performance and most importantly to me: expandability. One of the features of the new unit is a SCSI port that lets me add additional drive cabinets without buying a completely new miSAN… AND I can use SAS or SATA drives with the new controller. Very cool.

What about my original issues with the miSAN? I’ve been told by my Cybernetics rep that the issue with warning before removing a LUN and the issue of needing to reconfigure the unit from scratch when you upgrade software have both been addressed with the new 4.0 software, though I have not verified either at this time. All in all we are quite happy with the miSAN after running it for over a year, and the new unit is “the same only better.” While I still don’t think they are in the same league as Equallogic as they like to claim (especially regarding management and user interface), there is no doubt that the miSAN has extremely high bang-for-the-buck compared to its competition.

The first order of business was to take care of Public Folders. Earlier in the process I’d set up a new Public Folder DB on the Exchange 2010 box, and told Exchange 2007 to replicate all of our existing public folders to this new db on the 2010 box as well. <aside> Yes, I know public folders are supposed to be deprecated, don’t use them, blah blah blah, but we use them extensively for a few specific things with great success and SharePoint just isn’t worth implementing for that functionality. It’s like using a sledgehammer to drive in a thumbtack </aside>

So, at this point I had an Exchange 2007 box still running, with no user mailboxes on it (but with public folders on it) and an Exchange 2010 box holding all user mailboxes and replicas of the public folders. Here’s how I proceeded to remove Exchange 2007 from my environment:

I started by following this article from Microsoft. Specifically, I ran

Get-PublicFolderStatistics -server <Exchange 2007_Server_Name> | fl | out-file C:\PFstat.txt

Looking at the results I could see all of my public folders and all of the system public folders and a bunch of info that’s irrelevant. Cool. I didn’t bother running the other two Get-PublicFolder commands.

Next I ran

MoveAllReplicas.ps1 -Server Source_Server_Name –NewServer Target_Server_Name

from the Exchange 2007 box (per the article), and for some reason it kept throwing an error about a missing parameter. I then tried the exact same command from the Exchange 2010 box and it worked fine. After running the MoveAllReplicas.ps1 script I periodically re-ran the above Get-PublicFolderStatistics command to check on the progress. Sure enough, the public folders in the PFstat.txt started falling off one by one. The article says wait up to 2 hours for this to complete. Believe them. I did this at the end of the work day and waited about 90 min and there were still two folders being reported in the file, but when I got here this morning and ran the command again it resulted in an empty file. Yay!

The next step (still following the above MS article) was to remove the actual Public Folder store (I used the Exchange 2007 Management Console) but it resulted in an error stating that it was the default public folder db for the existing (but empty) mailbox db and couldn’t be deleted. So I proceeded to whack the now-empty mailbox db on the Exchange 2007 box, and then tried to delete the public folder db again, and this time it gave me a really bizarre error:

Error:
Object is read only because it was created by a future version of Exchange: 0.10 (14.0.100.0). Current supported version is 0.1 (8.0.535.0).

A quick Google for that error resulted in lots of hits (apparently this is a known bug when Exchange 2010 is already introduced into a 2007 environment) but quickly led me to this article, and I used ADSIEDIT.MSC to delete the public folder db from AD manually per the instructions. I then looked in the Management Console to verify that the public folder db was indeed gone. Yup!

The next step was to actually remove Exchange 2007 from the server via Control Panel | Programs & Features. The process started and then came back with an error that there was a send connector associated with this server and it couldn’t be uninstalled until it was moved or deleted. I checked in the Exchange Management Console and sure enough the send connector I’d set up to allow mail to go between the 2007 and 2010 boxes was still there. I deleted it, re-ran the uninstaller and this time it finished without a hitch.

The final step was to remove the Exchange 2007 box from AD and turn it off. Just for good measure, I took a final Veeam backup of this Exchange 2007 VM, just in case there is something on the file system I’m forgetting about that I might need in the future. Clearly there is no Exchange info on it that would be useful now, but I already had the veeam backup set up and it was simple to do, so I did it.

We’re now back to running a single Exchange 2010 box, 2007 is a fading memory, and all seems well… so far!

After messing with it for a few days and getting nowhere, I finally cried “uncle” and opened a Microsoft support incident. After a few days of back-and-forth with front-line support, they finally cried “uncle” and escalated my case. Thankfully the new support tech identified the issue and had it fixed within 10 minutes. Here’s what it was…

In Exchange 2010, Outlook clients don’t do MAPI directly to the mailbox server… instead they do MAPI to the CAS. As part of this change, there are settings in the OutlookProvider object that let admins control the Outlook Anywhere settings (among many other things) on Outlook 2010 clients (and prior versions of Outlook ignore them). Specifically, the OutlookProviderFlags are what control the Outlook Anywhere settings, and in my case they were “wrong.”

From a Exchange Management Shell prompt we did:

[PS] Get-OutlookProvider | fl

which resulted in output similar to this:

RunspaceId           : c899b821-35ad-4187-b083-98748aba41ed
Server               :
TTL                  : 1
OutlookProviderFlags : 67
AdminDisplayName     :
ExchangeVersion      : 0.1 (8.0.535.0)
Name                 : EXCH

<snip>

Notice that in my case the OutlookProviderFlags are set to “67”, which is quite bizarre because the only legitimate settings for that field (per the link above), are ServerExclusiveConnect or None! (and furthermore, according to the same docs:)

“For Outlook 2010 clients that access Exchange over both organization intranets and the Internet, the recommended value is None, which is also the default setting.”

The simple fix for this was to run

[PS] Set-OutlookProvider EXPR –OutlookProviderFlags:none

Because there are three different providers (EXPR, EXCH, WEB) and all of them in my case were set to “67”, we ran the same command three different times, substituting the proper provider name into the command each time. After that, we restarted IIS and voila!… I could now launch Outlook and the “On fast networks…” setting remained UN-checked, just like it did with Outlook 2007.

Why on earth were my OutlookProviderFlags set to “67” when the default is “none”? The best guess is that I ran a script shortly after installing Exchange 2010 that sets all HTTP URLs to the same value (so you don’t have to poke around in Exchange Admin console hoping you got them all) and somehow this script set that attribute, whether intentionally or via buggy behavior is unknown. In any case, the problem is solved and we’re back in business, ready to move more users to the new server.

UPDATE: I’ve since gone back and looked at the script I ran, and there are zero references to OutlookProvider, so there’s no way it was the culprit. So the “67″ mystery remains as such…

Well, the consensus is wrong! I vaguely remembered reading something about this in my favorite Group Policy book Group Policy Fundamentals, Security and Troubleshooting by Jeremy Moskowitz and sure enough found the section on how to create a GPO that adds to the existing administrators group instead of overwriting it. I asked Jeremy’s permission to repeat the following text from his book:

Tricking Restricted Groups So It’s Not “Rip and Replace”

It is possible to trick the Restricted Groups function into allowing you to simply add members to a group (and not rip and replace them). As we saw earlier, any time we try to use “Members of this group,” it becomes a “rip and replace” for the members of that group. So, that’s precisely not what we’re going to do.

Instead, if you want to trick Restricted Groups into adding a domain-based group into a local Group Policy (and not rip and replace what’s already there), perform the following steps:

1. In Active Directory, pre-create the group you know you’ll want to add to the existing local administrators. In my example, I’ll use the group called DesktopAdmins.
2. Open the GPO and traverse to Computer Configuration | Policies | Windows Settings | Security Settings | Restricted Groups.
3. Right-click Restricted Groups, and choose Add Group from the shortcut menu, which opens the Add Group dialog box.
4. Click Browse to open the Browse dialog box, and locate CORP\DesktopAdmins (obviously, choose whatever your AD group actually is)
5. Then, you’ll click the Add button in the “This group is a member of” section of the Properties dialog box. You’ll then be able to specify “administrators” in the second group name. Again, since we’re talking about the local Administrators group, you simply type it in. Don’t browse for it.

Once you’re done, you can wait for the Group Policy refresh cycle (or, type gpupdate.exe on your target machine) and see the results. You should now see your AD group listed as a member of administrators along with any members that were already present before you applied the GPO.

Jeremy also says that the newer Local Users and Groups GP preference is a much better mechanism to use vs. the Restricted Groups policy, as the former provides far more control over local groups. The only reason to use Restricted Groups is when you need to add a domain-based group to a local group… like when wanting to add an AD group of helpdesk personnel to the local administrators group of all your client machines.

Thanks to Jeremy for giving me permission to repeat this small section of his book. If you deal with Group Policy at all, his books are must-haves in my opinion! They really helped me understand Group Policy in a way other resources haven’t. You can check them all out at gpanswers.com/book

I’ve been running Fusion since version 2.0 and never gave Parallels another look. In general I’ve been quite happy with Fusion and had no serious complaints, though there is always room for improvement. At this point I should explain that I don’t just run a virtual machine on my current MacBook Pro as an “aside” to run the odd Windows program or two. On the contrary, my Windows 7 Enterprise VM is my primary work environment. I love the Mac hardware, and need a Mac to support our large Mac base here, but I’m just not a huge fan of OSX for my daily activities. Sorry Apple fanboys, but Windows is just easier for me to use. Anyway, my point is that since I work in a virtual machine 95% of the time for everything I do on my computer, I’m VERY VERY familiar with all of the quirks and performance bumps that come with running in a VM (But I wouldn’t give it up! Having my primary work environment virtual has SO many advantages that I will likely never go back to running on bare hardware) so I consider myself pretty qualified to judge a VM’s preformance under heavy use.

As I said, I was happy running Fusion, but recently I saw this article detailing a head-to-head benchmark between VMWare Fusion 3.0 and Parallels Desktop 5 for Mac, with the overall result being that Parallels 5 is about 43% faster than Fusion 3.0 running Windows 7. This seemed like a crazy result (in some individual benchmarks Parallels was supposedly 80% faster than Fusion) so I just had to download the trial and take a look for myself.

So, I grabbed a trial copy of Parallels Desktop 5 for Mac and installed it, then used it to convert my existing Fusion 3.0.2 VM to Parallels format in a new location (leaving my original Fusion VM untouched). I fired up the new VM and it went through a process of automatically uninstalling the existing VMware Tools in the Windows 7 guest and replacing them with Parallels Tools. After that process, the VM rebooted for a final time and started up…

My first reaction to Parallels 5 was quite negative. While the Win 7 startup time (from booting the VM to seeing the CTRL-ALT-DELETE prompt) was impressive, once I entered my password it took about 90 seconds to get to the desktop, much of which the screen was entirely black. But once Windows finally got to the desktop, I quickly became impressed. I don’t have any scientific benchmarks to give you (that has already been done elsewhere, anyway) and fully admit that all of my observations are completely subjective and “seat of the pants” feel, but to me Parallels immediately seemed more responsive in nearly every way.

One of my ad-hoc tests of Aero performance in Fusion was to do a “window shake”… that is, take a window that is open, grab it, and shake it around with the mouse as fast as you can. The “smoothness” of the window moving around that fast is, to me, one indication of how fast Aero is being rendered. I can’t give a number, but Parallels passed the “shake test” with much smoother results than Fusion did. Then there’s CPU utilization. When watching Flash in Fusion, the CPU gets pegged at 100% (I have a CPU gadget on my desktop) and while the video usually plays fine, glitches in audio are not uncommon. With Parallels, the CPU is almost pegged at 98% while watching Flash content, but more important, the audio hasn’t dropped on me once… yet.

In general Parallels just seems faster (though not “blown away, OMW!” faster) at nearly every task I give it… suspending/resuming the VM; file access to the OSX host; CPU utilization doing the same things that caused higher utilization in Fusion; USB devices are handled better, etc, etc. There are also many “little things” that Parallels seems to do better. One example is the CONTROL key. With Fusion, when in the Windows VM if I needed to press the CTRL key (like when selecting random items from a list), I would have to use ALT-CTRL (FYI, I use an external WINDOWS keyboard connected to my MacBook Pro when at my desk) to get an actual CTRL keypress. With Parallels the CTRL by itself works just as expected. Could this be tweaked/fixed in Fusion via custom keys? Probably… but my point is that out-of-the-box Parallels seems to be more polished, more refined, and faster at nearly every task.

Finally, I have not evaluated the “integration” features of Parallels (OR Fusion), where the products integrate Windows with the OSX desktop to provide a more Mac-like experience with Windows programs, mainly because I’m not interested in that functionality. That said, in my brief look around it seems that Parallels has more options and “views” in this regard (with names like “Crystal”, “Coherence” and “Modality”) over Fusion.

The end result? I have been sufficiently impressed with Parallels Desktop 5 for Mac over Fusion 3 to convert to it and buy a copy. For me, it’s that much better. In my opinion the Fusion team really has their work cut out to regain the ground they’ve lost to Parallels. If they ever do, you can bet I will give them another try. I’m not a label snob and don’t really care about the brand name… I just want the product that works the best for me, and today that product is Parallels Desktop 5 for Mac.

Oh yeah.. what about that long login time? It still occurs, and is the only real complaint I have about Parallels. It still takes 60-90 seconds from the time I enter my password to get to the desktop (most of it a completely black screen), but to be honest I haven’t done any investigation into why it’s occurring. Why? Because I rarely reboot my VM (I suspend/resume it most of the time) and I’m also not convinced that it’s necessarily Parallels fault. Remember, I did convert my Fusion VM directly to Parallels, so who knows if some ghost of Fusion is lurking around in there somewhere? The only way to truly test would be to install a fresh Win7 VM and see if the same thing happens, but at this point I’m not willing to do that. If anyone has an idea about this long login time, please let me know!

Example: One of the main hashtags I follow is #citrt <aside> if you’re involved in church IT and aren’t familiar with the Church IT Roundtable, you are really missing out on an incredible opportunity to network with your peers! Check out www.citrt.org for details. </aside> Anyway, I follow #citrt and this scenario routinely occurs:

@Someone I just installed our new server! #citrt

@SomeoneElse RT @Someone I just installed our new server! #citrt

@AnotherSomeoneElse RT @SomeoneElse @Someone I just installed a new server! #citrt

and on and on… you get the idea.

What happens is that those of us following the #citrt hashtag now have to SEE essentially the same tweet X number of times, until the “RT loop” finally dies out. Wouldn’t it make much more sense to simply remove the #citrt hashtag when you retweet? The point of a hashtag is to let those following said tag see the tweet, right? So if I see a new tweet come down the pike with #citrt, I already know everyone else following #citrt also saw the tweet. So, when I retweet it, why not simply remove the #citrt because it is now redundant?

Another way to look at it is this: re-tweeting exists (in my opinion) to “re-broadcast” useful information to your followers, not to the same people that you know saw the original tweet, right? Am I making any sense here? All I’m saying is that when re-tweeting, take two seconds to look at the tweet and consider who has already seen it (which is everyone who is following any hashtags that might be included in the original tweet) and do us all a favor and remove those hashtags before re-tweeting! Now only your followers will see your useful retweet, and those of us following the original tag don’t have to endure seeing the same RT for an entire day.

Clear as mud?

Jim

P.S. The intent of this article is not to pick on #citrt specifically, it’s just the one I see this happening on most frequently. This phenomenon also happens with all sorts of hashtags

Last summer I started using Likewise Open as an AD client on my MacBook Pro, which simply allows me to log into my Mac using Active Directory credentials. While in general the software has done its job, there are some quirks that I’m tired of living with (seemingly random LONG login times being the most annoying) AND I wanted to try a client that can handle DFS shares, so it was time to retire Likewise Open and try AdmitMac. But there’s a problem. When you start using Likewise Open, it lets you “migrate” your existing local Mac user to a new location, which lives under /Users/local/DOMAIN/<user> on the Mac. However, when you un-install Likewise, there is no “revert” function to put the user in this non-standard location BACK to /Users/<user> where it belongs so that you can log into it as a normal local user.

The process of getting things back to normal is very simple and here’s what I did:

1. Logged out of the Mac and logged back in as ROOT
   
2. Created a new “jimm” user on the Mac using the normal method in System Preferences | Accounts and gave it administrator rights. This is the new local user I need to use as “me” since the one under /Users/local/DOMAIN/jimm would no longer be accessible once Likewise was uninstalled.
3. Used the GUI to copy ALL of the directories and files under /Users/local/DOMAIN/jimm to /Users/jimm (which is where my new local account lives). Told it to overwrite any existing directories and files when prompted. In case it’s not obvious, all I’m doing here is copying my entire user environment that was under the Likewise location to the correct location for my local user. Logging in as ROOT let me have full access to the file system to accomplish this copy… the only problem being that the files were now in the correct location with the WRONG owner information.
4. Launched Terminal and typed cd /Users/jimm
   
5. Typed chown -R jimm:staff * This command changes the ownership of all directories and files within my user hive to have the owner “jimm” and group “staff.”
6. Logged out and back in as my new jimm user, and verified that everything was correct in my environment and all of my files were accessible.
7. Used the Directory Utility to unjoin the Mac from my domain.
8. Opened Terminal again and typed sudo /opt/likewise/bin/macuninstall.sh to uninstall Likewise. Using sudo was necessary here as I was logged in as myself instead of ROOT.

Now Likewise is completely gone, my user environment is in tact and back in the correct place, and I’m ready to try AdmitMac. But that’s for another post…

It’s somewhat difficult to distinguish fact from fiction in the various forums discussing the issue because of the inevitable untruth and hyperbole that gets mixed in with facts, but Seagate has finally released a KB article on the subject, so it appears to be a Real Problem after all.

There is apparently a firmware bug in multiple Seagate models that, when it decides to rear its ugly head, completely bricks the drive and it can’t even be seen by the BIOS. From the user’s standpoint, the data is completely gone, though it can still be recovered by a competent data recovery service.

Oh yeah… did I mention that our new SAN has twelve of these drives in it? Joy. At least we’re (thankfully) not using the SAN in production, yet. In any case, if you have large Seagate SATA drives anywhere in your organization or home PCs, check them out before it’s too late…

“Don’t vSphere the Reaper…”

“The only thing we have to vSphere is vSphere itself…”

“vSphere: The OS with Big B….”  Errr…. scratch that one. Oops! That made it worse… I will preemptively apologize to those I’ve just offended. Sorry!

So, what’s the point of all that? Nothing, really. Just my silly ramblings over what I consider a silly name change. But I’ll be the first to admit that I’m not a creative marketing type, so maybe it will eventually make sense and roll off the tongue without sounding weird. [insert rimshot]

[tap tap tap] Is this thing on?

Hmmm… parts falling out of electronics is rarely a good thing. Neither I nor Mike (my IT Support colleague) had any idea what it was, and couldn’t find an obvious place it had broken away from on the motherboard. So Mike proceeded to SpinRite the drive as we assumed it was the culprit, just like last time.

While the drive was being tested I opened our spare CUE module for a comparison, and AHA!, there it was… the part that had fallen off was a small metal “U” that had been soldered to the motherboard, serving as an anchor for the clamp that holds the CPU heatsink down. That spring mechanism is under tension, and apparently the solder joints had given out and the “anchor” came free.

So, the drive test finishes and of course finds nothing wrong. We put it all back together, pop the module back into the router (sans heatsink anchor) and fired it up… voila! It came up and worked perfectly. Our best guess as to what happened is this: The heatsink anchor popped off the motherboard, shorting some random traces, crashing the server. Once removed, the system was able to operate fine.

Sometimes you do get a weird one