Oct
01
Posted under
Church IT My only machine for work is a mid-2010 2.66GHz, i7-powered MacBook Pro on which I run (and “live in”) Windows 7 Enterprise x64 the majority of the time – in a Parallels virtual machine. I won’t go into the reasons why I’ve chosen this setup, why I don’t use Boot Camp, etc, but suffice it to say that there are so many advantages of having my work “PC” virtualized that I will likely never go back to running my working environment on native hardware, and it has served me very well for the last three years (I’ve upgraded Macs once in that timeframe).
That said, living in a virtual environment – while pretty close to native performance – it can still have some performance issues, particularly when you’re trying to do things in the host OS (in this case, OSX 10.6.whatever) and the VM at the same time, and disk performance is one area that suffers the most. That lead me to seek out my first solid state SATA drive, hoping it would provide some useful performance benefits. I did some research, and at the suggestion of Chris Green I ended up focusing on the OWC Mercury Extreme Pro SSD line. It goes without saying that not all SSDs are created equal, and you really can get stuck with a lemon if you’re not careful. As of this writing, the OWC seems to be among the best using current SSD technology and doesn’t suffer from the “write cliff” phenomenon (where write performance drops off dramatically after just a few months to a year of reasonable use) like so many other drives do… even the SSD drives that ship from Apple in MacBook Pros aren’t considered to be all that great. You really need to do your homework before dropping this much $$ on a SSD.
So, after deciding to take the plunge I ordered a 240GB OWC SSD and received it the next day (got it from Zones… with our discount I couldn’t find it cheaper anywhere else.) Installation took about 15 minutes and the restore of my Time Machine backup took another two hours. Upon first boot I could immediately see that things were running faster, as I got to the OSX login prompt in about 10 seconds. I then proceeded to boot my Parallels 6 Win7 Enterprise x64 VM (which took about another 8 seconds to get to the login prompt) and fired up my disk benchmark. Here are the results:
This chart shows the disk performance of the VM with the native 500GB 7200RPM Seagate SATA drive that shipped in the MacBook Pro:
The first two tests are sequential read/write at two different block sizes. The second two tests are random read/write at two difference block sizes.
And here’s the same test after installing the OWC Mercury Extreme 240GB SSD:
It doesn’t take a rocket scientist to see that the SSD drive blows the doors off of the rotating disk. But the pictures can’t convey the “seat of the pants” increase you feel when running a machine with such a drive. It becomes so responsive that it changes the experience in fundamental ways. The CPU becomes the new bottleneck because the drive serves up data so fast for multiple, simultaneously-loading apps (like occurs during Windows startup) that it gets pegged at 100% for seconds at a time while it deals with all the app data trying to execute at the same time.
Some of you might be wondering about the OSX side? I did run xBench in the host OS both pre- and post-SSD, but won’t take the time to post the numbers here as they are so similar to the VM numbers. They were in fact so close to the VM numbers that it’s an interesting aside to note that the disk system in a Parallels VM is almost identical to native performance. Pretty cool. The best way I can sum up the SSD experience is to paraphrase Ferris Bueller:
I love using it. It is so choice. If you have the means, I highly recommend picking one up.
Sep
29
Posted under
Church IT I used to be a Fusion user, but when Parallels 5 came out, with its markedly superior performance (at least compared to Fusion 3.0.x at the time), I made the leap. I’ve been generally happy with Parallels 5 and have no real problems with it, so when Parallels 6 recently arrived I thought it would be worth the upgrade as they were touting yet more performance improvements, especially in the 3D graphics area.
The first problem occurred when I tried to buy Parallels Desktop 6 for Mac from www.parallels.com. Because I didn’t want to use my credit card directly on their site, I chose the Paypal method of payment. After entering and submitting my information, I got a screen that basically said “Thank you for your order. You will soon receive an email with instructions on how to download your purchased product.” U-huh. At no time was I actually redirected to Paypal to complete a transaction, so this message was obviously completely bogus and delivered in error.
The next problem occurred when I used their support number (listed under Contact Us at www.parallels.com) to inform them of the problem and after pressing what sounded like the correct calling tree path I got “The mailbox you’re trying to reach is full. Please try again later.” Uh-HUH. Needless to say I was a little miffed at this point, and I tweeted my disappointment and received a response from Parallels with a different number to try.
This time I did get through… to a barely-intelligible foreigner (call me a bigot if you must, but when I call a US number I expect to be able to converse with someone I can understand, speaking coherent English). He told me to try a different browser. I tried four (between both Mac and Windows) and all had the same bogus “Thank you” page as the first time I’d tried to use the Paypal method of payment. I call back and get another unintelligible support person and this time I’m told I need to go to “Element5” directly to purchase Parallels, and he would email me the URL immediately. After painstakingly repeating my email address letter-by-letter (“J as in Jeronimo, I as in Idiot, M as in Moron”, you get the picture…) he said the email was on its way. Which of course never arrived.
So then I decided to do what I should have done from the start: download the trial version to see if the upgrade is even worth it. The install went smooth and my Windows 7 Enterprise x64 VM fired right up. However, I’m thoroughly unimpressed. There is no discernable performance improvement like they claim, and within the VM the Graphics portions of the Windows Experience index are actually LOWER than they were with Parallels 5. (5.9 in v5 vs. 5.4 in v6). Then I discovered that there is a serious problem with the trackpad on my Macbook Pro when running the VM Windowed or Full screen… two-finger scrolling is totally balky and unusable. A quick search shows many users complaining in the Parallels forums of the same problem.
All that said, this version of Parallels is nothing like the stunning performance improvements of version 5, and appears to have been rushed out the door way too early. It has all the hallmarks of “revenue-ware”… you know, when a vendor comes out with a “new and improved” version just to drum up upgrade revenue, when the core product is incomplete, has superficial changes, and doesn’t live up to the hype.
At this point I’m thankful Parallels’ purchasing process is so broken and haven’t wasted my money. At least I still own version 5, which is great. But I don’t think I can easily downgrade to it and keep my existing VM. Sigh.
Jun
09
Posted under
Church IT About a year and a half ago I blogged about our new Cybernetics miSAN and in the subsequent comments detailed some of my issues with it. I was recently asked if these issues were ever addressed, and as luck would have it, the timing is just right as we’ve recently replaced our original miSAN with… another miSAN! Here’s how it all came about…
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.
Jun
04
Posted under
Church IT Nothing Earth-shattering here… I’m blogging this mainly to document it for myself. Anyway, we recently migrated from a single Exchange 2007 server (running all roles) to a single Exchange 2010 Server (running all roles), and for the last month have been running a “mixed” environment with both servers up and passing mail back and forth. I’ve slowly been moving users over to the new box, and yesterday moved the last one. Then it was time to figure out what needed to be done to retire the Exchange 2007 box (just a VM, really), which turned out to be a bit more complicated than I’d thought it would be…
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!
May
06
Posted under
Church IT I installed my first Exchange 2010 server into our existing Exchange 2007 environment a couple of weeks ago, and rather than migrate all mailboxes to the new server at once, I (thankfully) elected to move just the IT people there to put the new server through its paces before moving everyone else. After the initial configuration and moving of my mailbox, I discovered a problem that I could not fix: No matter what, the Outlook Anywhere setting called “On fast networks, connect using HTTP first, then connect using TCP/IP” would automatically be set. If I un-checked it, I could restart Outlook and get in the FIRST time using TCP, but the setting was automatically enabled (checked) again, so subsequent restarts of Outlook 2010 would prompt for credentials. We have standardized in leaving On fast networks, connect using HTTP first, then connect using TCP/IP set to OFF, so that when on the LAN/domain Outlook clients will use SSO and not be prompted for credentials, and when outside the LAN they will fall back to using Outlook Anywhere and prompt for credentials… so this behavior was a problem.
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…
May
05
Posted under
Church IT Today in the CITRT IRC chat the subject of creating a GPO to add AD groups to the local administrators group on a client came up. The consensus was that when you use GPO’s “Restricted Groups” functionality, the effect is that it works, but completely replaces the existing local administrators group with the one you specify in the GPO. Needless to say, this is often undesirable and makes Restricted Groups a bit useless if you don’t want to kill the existing members but add to them.
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:
- 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.
- Open the GPO and traverse to Computer Configuration | Policies | Windows Settings | Security Settings | Restricted Groups.
- Right-click Restricted Groups, and choose Add Group from the shortcut menu, which opens the Add Group dialog box.
- Click Browse to open the Browse dialog box, and locate CORP\DesktopAdmins (obviously, choose whatever your AD group actually is)
- 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
Apr
06
Posted under
Church IT Way back when I got my first Macbook, one of the first virtualization apps I ran on it was Parallels. At that time it was the only game in town, and worked remarkably well on that first generation Intel Mac. But then VMWare Fusion eventually came along and I moved to that when I switched to a newer Mac, largely because they were the first to do Aero 3D effects for Windows Vista/7 VMs, and because we are already a VMWare shop for our server virtualization and keeping it all in the family made sense.
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!
Mar
24
Posted under
Church IT Am I the only person who thinks retweeting is broken? We probably all agree that the lack of RT standardization is an annoyance (I detest the “via” format, for what it’s worth), but that’s not what I’m talking about. I’m referring to the lack of responsible editing of the tweets we are retweeting… specifically, the removal of hashtags that were part of the original tweet.
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
Feb
17
Posted under
Church IT Wow… has it really been a YEAR since I last posted to this blog? Unreal. Anyway, I recently asked around if anyone knew how to recover a Mac user account AFTER uninstalling Likewise Open. None of my CITRT peeps had any idea, but someone in the Likewise forums gave me a hint, and this is how I did it. But first, let me back up a bit and explain what I was trying to accomplish…
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:
- Logged out of the Mac and logged back in as ROOT
- 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.
- 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.
- Launched Terminal and typed cd /Users/jimm
- 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.”
- 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.
- Used the Directory Utility to unjoin the Mac from my domain.
- 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…
Jan
16
Posted under
Church IT Say you have a nice 1 Terabyte Seagate Barracuda drive that appears to be working fine. You power the host system off, then back on… and it fails to see the drive. No matter what you do, you can’t get the drive to be seen by the host machine again. Sound unlikely? Not if you have one of the various Seagate Barracuda SATA drives that have a nasty bug… Search the net for Seagate Barracuda Bug for many many threads on the subject of these drives failing prematurely.
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…