OnQ : Tools

LogMeIn to the Rescue Again!

eriq — Thu, 07 May 2009 20:55:40 GMT

We use and recommend the use of LogMeIn for some of our clients who need the ability to remotely access their workstations while away from the office. True, in some situations that type of remote access tool presents potential security concerns, but in those cases where it makes sense, LogMeIn has been a solid tool. Today I was reminded of one other reason I use it.

It won't come as a shock to anyone who reads my blogs that I'm primarily a Mac user. My main workstation is a Mac Pro (running several Windows "workstations" in Parallels and Fusion). It should also come as no surprise to know that every once in a while, a Mac will have some kind of problem and need a swift kick in the pants. Or at least a timely reboot (and I'm not talking about rebooting when updates come out). It doesn't happen very often, but today was one of those days.

I was testing something for a customer and I lost the video display on my Mac. Completely. Both monitors, gone. Apps were still responding (I could tell, because I tried to switch around within apps and certain keystrokes would generate an alert sound) and I could access the few file shares I have open on the Mac. But I couldn't see a thing, so I was driving blind, literally.

I didn't want to just do the hard reset, because I had a large number of apps open in my main Vista VM. I also had my Windows 7 VM open, as well as a 2008 Terminal Server with a number of apps running. I had a few Mac apps open, but nothing that wouldn't close down successfully with a normal shutdown.

I have LogMeIn installed on the Mac, so I first tried to access the Mac that way, in case it was a video card problem. Nope, when I opened the LogMeIn remote session, the screen was black and nonresponsive there, too.

I used RDP to connect into my Vista workstation, the Windows 7 machine, and the terminal server, and shut each of them down remotely. Then, just as I was about to go push the big power button on the front of the Mac, I saw the Options link in LogMeIn. Sure enough, in there was a button to initiate a restart of the machine, so I clicked it. And the Mac started a normal reboot process and came right back up.

I'm not sure what caused the display to go funky, but I was able to recover fairly easily. And I thought it was a tidbit worth sharing, since I hadn't used that feature before.

On Securing RDP

eriq — Fri, 21 Mar 2008 01:26:00 GMT

Last December, I worked out an arrangement to better protect our clients for whom we provide primary support. This involved finding ways to tighten access their severs via RDP (the infamous port 3389). There are a lot of different takes on controlling access to port 3389 out there, from simply not allowing it at all through the firewall (which works for SBS boxes running Remote Web Workplace, provided there's not a problem with IIS on the box at the time you want to access it) to configuring the firewal to allow inbound port 3389 connections only from specific IP addresses. For our purposes, neither of these options, nor the other similar variations, really worked for the way we conduct our business.

Enter Dana Epp and Scorption Software. Dana is a Security MVP from Vancouver whose software development company has been developing security products designed fo the SMB market for a couple of years.

After working with two of his tools, AuthAnvil and RWW Guard, we finally developed an approach that mitigates the risks of opening port 3389 to the internet, yet still allowing our opration a reasonable level of access for support and maintenance. Here's the approach we're taking.

Create a secondary administrative account with the same name across all of our supported servers.
Change the password on the Administrator account to be a really, really secure password.
Modify the local security policy to deny the Administrator account the ability to log in via terminal services, effectively limiting the Administrator account to a local console login only (which also does not affect any services running with that account).
Install the WinLogon Agent component of AuthAnvil on each client system and point it back to the AuthAnvil system running on our servers.
Configure AuthAnvil on our servers to have a grouped account, whose name matches the secondary administrative account we created on our supported servers, and add local users to that grouped account who are allowed to log in to the remote server.
Add the Administrator account to the AuthAnvil Override security group on the local server so that the Administrator account does not require a token to log in to the server.

We have started rolling out this configuration this month, and so far it is working according to plan. The benefits of this arrangement include:

Local access to the sever is still possible with the Administrator account and no security token.
Remote access to the server is limited to the secondary administrative account, which also requires the use of a security token to successfully log in.
The access logging in AuthAnvil gives me an accurate accounting of hich of my staff accessed one of our support servers and when.
When staff turnover occurs, access to remote systems is denied in a single step by disabling the employees token in the main AuthAnvil system.

So for the cost of equipping my staff with the security tokens, we are able to increase the security of our supported systems with two-factor authentication, while blocking remote access to the Administrator account at the same time.

None of this would have been possible without Dana's efforts to bring quality security products to the SMB space at an affordable price. It's a very small price to pay for the enhanced security benefits our client base is receiving.

On Updates and PERCs

eriq — Mon, 28 Jan 2008 14:45:00 GMT

I've had a few comments show up on the series of PERC 5/i posts I had early in 2007. There have been a few questions about the status of things, so rather than respond in the comments, I thought I'd summarize what I know at this point in a separate post.

Bottom line, the alarm status of the PERC 5/i has not changed, nor will it in all likelihood. In discussions with the engineering folks at Dell, apparently there were a number of people who complained about the alarm with such ferocity that the design team decided it was best to take it out altogether. Akin to driving in a nail with a sledgehammer, I think this was a misguided and completely incorrect overreaction to the problem. If Dell wanted to make the default setting on the controller to have the alarm OFF instead of ON, I would have been fine with it. Make me enable the audible alarm if I want it, but leave it off for those who don't. But to completely remove the functionality is just beyond me.

At this time, I cannot tell if the next series of the PERC controller will have this functionality restored. The engineering folks that I spoke with said that the feedback they're getting is still in favor of having the alarm removed. I said "you're talking with the wrong people, then." I invited them to have their researchers include me in their feedback request, and I'd be more than happy to add the logical reasons to have the ability to have an alarm present but quiet by default. If you're in the same boat as I am, please take a moment to contact Dell Support and voice your thoughts on the matter. Apparently (as I've been told), they listen to loud feedback.

Secondly, on the issue of proactive monitoring, Dell still does not have a tool that will generate an alert if the array goes into a degraded condition. We have been using HoundDog to provide proactive monitoring of the health of the array for my systems with the PERC 5 controllers, and it has worked very well for our operation. You do have to install the Server Administrator tools to generate the SNMP alerts that HoundDog picks up on, but cost of the HoundDog service and running Server Administrator on the box is far less than the cost of not knowing that an array is having trouble. There are, of course, a couple of quirks. One, the SMNP trap will alert on battery conditions on the controller as well, and not tell you it's a battery issue in the alert. If the server gets powered off for any reason, the battery on the controller starts "draining" to maintain the configuration information, and when the server is powered back on, the battery goes into "recharge" mode, which triggers an SNMP even in Server Administrator, and then by HoundDog. I haven't been able to find out how to modify that, but it's probably good to know about battery conditions, so I'm leaving it alone. Two, not all Dell servers run Server Administrator, specifically the SC-series servers. I have one SC server with a mute PERC controller, and I'm tring to figure out how to monitor that. SNMP doesn't work, as Server Administrator isn't present to generate the SNMP configuration that HoundDog is looking for. I downloaded and installed the LSI software, but it has no mechanism for generating alerts, so I'm still digging on that one.

So we're not fully there yet, but getting comfortable. I will not be purchasing an SC-class server from Dell in the future, but outside of that, HoundDog has given me what I need to keep my team alerted to any problems with array controllers at a very minimal cost. I would still prefer to have the option of dealing wiht an audible alarm, and I still mention my frustration with that every time I call Dell support (which really isn't that often, but I did speak with the original tech who took my call last February over the past week about another issue, and he rememberd who I was and brought up the subject himself).

On Conversion

eriq — Sat, 29 Dec 2007 13:12:00 GMT

Amy Babinchak and I gave a presentation at the Trend Micro/SBSFAQ.com SMB Security Summit in Sydney (talk about alliteration) in November, and we discussed the security implications of providing remote support to clients. In the discussion, we mentioned a number of tools that can be used to provide remote support. Historically, I'd been using two different tools, primarily for my cross-platform clientele. For about two years, I've had a subscription to GoToMeeting that I've used for a significant majority of desktop support as well as for those clients who had problems with RDP and/or RWW. For about $40/month, I was able to have as many different support sessions (one at a time, as I purchased as single seat) as I wanted, and was able to resolve many problems. GoToMeeting is primarily geared at webcasts, but it's ability to allow diffferent attendees to "share" their desktops made it possible to not only view but remotely control another computer. As I mentioned, I used this quite a bit for desktop support, but also some on servers. The downside to GoToMeeting is that it requires Java on the remote device, and not all servers have Java installed, and not all users want Java installed on their servers. I'm not saying that Java is a bad thing, but for most servers who do their job sitting headless in a corner (where they should be), Java can be an extra load and tool that needs to be updated regularly for security purposes. And, the process to get the remote software loaded and configured for remote control could be a bit smoother. Still, it's a solid tool, which allowed me to record sessions as needed, and it just flat worked. But GoToMeeting does not support the Apple platform, and since a lot of my business involves those cross-platform situations, G2M didn't help.

Actually, until Adobe introduced Acrobat Connect, there really weren't any options for remotely controlling a Mac. Sure, you could walk the person through turning on the VNC services build into Mac OS X, then either configure the router to allow inbound VNC or make a VPN connection into the remote network to then access the VNC services, but it's just ugly, and when you're trying to troubleshoot a Mac problem, often times the effort to get VNC access working just wasn't worth it. But Acrobat Connect uses Flash technology as it's communications layer, and they developed the tools to be able to allow a Mac to connect into the system and be the controller or the controlled system. Given that I have a Mac PowerBook that I carry with me in the field, this was beneficial as I was able to enter into remote sessions controlling either a PC or a Mac from my PowerBook when I was out of the office. This was much more efficient for me than connecting to my terminal server to run GoToMeeting. And at about $50/month for the single user subscription, it made sense. Now I could control either Macs or PCs using Connect, and I could do it from either my Mac or my PC, whichever was more convenient.

OK, there is one other tool that did allow control of a Mac before Acrobat Connect came along. That was LiveMeeting. It had the same metholdology as G2M and Connect, in that it is a conferencing application that allows for remote control, but from a cost standpoint, it really wasn't a player in the SMB market. Microsoft did, and I think still does, use LiveMeeting to provide remote support when you call CSS for support, but hey, they own the technology, so it's easy for them.

During the presentation, Amy spoke about the tool she has been using for a couple of years, LogMeIn Rescue. Unlike G2M and Connect, LogMeIn Rescue was designed as a support tool, not a conferencing tool that could be used to take control of a remote system for support. There were a lot of great features in Rescue that aren't available in G2M or Connect, such as tools to collect hardward and software information about the remote system with the click of a button. One of the biggest "wow" factors for me was the ability to actually reboot the remote machine into safe mode and automatically reconnect with Rescue when it completed the Safe Mode boot. Holy cow, that's incredibly useful! But at around $100/month for a single technician license, I wasn't that taken as that covered the cost of both tools I was using to get me cross-platform support. Sure, the goodies that LMI provides over G2M and Connect were nice, but since I'd still have to keep Connect around for Mac support, dropping G2M in favor of LMI didn't make a lot of fiscal sense.

That is, until I saw that LogMeIn was working on providing Mac support, not only for their LogMeIn Free product, but also for Rescue. So in mid-December, I signed up for a free trial of LogMeIn Rescue to test out the Mac functionality.

And it worked. Flawlessly.

For two weeks, I used LMI for every remote call, Mac and Windows, and was just amazed by the power of the solution as well as the ease of use for the client end. The client-side experience was very straightforward, not requiring a whole lot of instruction on my part to get the user connected and me in control. LMI is not based on Java or Flash, but its own technology tools that install easily. There's also an easy option to get the tool to install as a service, so you can log out and log back in to the remote device with a different username/password without having to necessarily give that information to the remote user. But being able to have a single solution to give me Mac and Windows support as seamlessly as LMI does was the kicker.

So, as of January 1, 2008, I'm dropping G2M and Connect in favor of LogMeIn Rescue. The only drawback to Rescue is that I have to run the technician's console on a Windows system. There's not any public word about development of a teechnician's console that will run on a Mac. But given that I can connect to a terminal server and run the console from there, it's usable when I'm out on the road with only my PowerBook at my disposal. Not great, but it works. And I'm learning about so much more that Rescue does that Amy didn't have time to discuss during the presentation that I'm already considering getting a second technician license for my staff, rather than using the same license for all of us. And yes, I've already discussed this with the fine folks at LMI and that's perfectly within the scope of the license.

This is just one way I'm helping to ensure that the remote support we are providing to our customer base is as secure as possible. I'm in the process of implementing another system that I'll blog about when we get it done, as it gives me an entierly different level of control over who has acces to my client's systems, whcih helps protect them as well as us.

On Irony

eriq — Tue, 16 Oct 2007 13:38:00 GMT

For the last couple of months, I've been working (at the request of a couple of my clients) to enter the Apple Authorized Business Agent program with my business. I've had several clients who have started incorporating the Macintosh platform into their businesses and wanted to be able to help us get "credit" for the sale of Mac hardware that we've been discussing with them. Which, really, is the whole point of the Business Agent program. Two clients specifically have been holding off on Mac purchases specifically until we've got the program up and running so they could make sure we get the appropriate credit.

So how ironic is it that the first purchase that goes through our online store is none other than Susan Bradley? Not that Susan has been a Mac basher by any means, in fact, she has a Mac category on her blog (granted, there's a lot of links that point back to posts I've put up, but then her blog is read by thousands, and I'd like to personally thank both of you who are reading this blog). I just never would have dreamed that I'd help push a Mac sale into Susan's hands, or that she'd beat me to the blog post about it. OK, maybe I'm not so surprised that she beat me to the blog post.

Just goes to show that you never know...

On Revisits

eriq — Fri, 17 Aug 2007 21:27:00 GMT

Just a week ago, I had the notion to take a serious look at Fusion and Vista on my Mac and posted my initial observations about it. Those observations, as noted, were based on just a few hours work with the product. Over the next few days, I had an opportunity to really dig into different parts of the setup and get a lot of other experiences. So, a week later, I'm posting my next update to my experiences with Fusion and Vista.

In summary, it's off the machine. I had trouble, I tried to fight through it, I gave up. I lost a lot of productivity Monday and Tuesday, so I went back to my tried and true Parallels and XP to get business back on track.

That doesn't mean that Fusion and Vista don't hold promise. It just means that in my opinion, based solely on these experiences, I can't recommend Fusion and Vista as a viable, reliable platform for business use. The rest of the post will shed a little more light into the whys of it all.

First, the background. I had initially created a 20GB HD partition for Vista under Fusion, and after installing Vista, Office 2007, and some of the standard SBS tools, the disk was at 65% full. I knew that wasn't going to hold water, and so I was planning on rebuilding the HD anyway.

Well, I got my opportunity earlier than I had thought/hoped. After a lengthy power outage on Sunday which knocked my Mac out of commission, I came in Monday and could not get Fusion to boot the Vista HD image at all. This was when I noted the lack of apparent disk image management tools in Fusion. As best as I can tell, if you have problems with a VHD file in Fusion, you're toast. Granted, I didn't spend a lot of time looking (then) for tools to repair the VHD, I decided that I'd go ahead and just reinstall into a larger VHD file and move on. So I blew away the Vista config setup and went on. I created a new profile for Vista with a 40GB HD, installed Vista, connected it to my SBS network, and installed Office 2007. I was in the middle of syncing my OST file for Outlook when my Mac crashed again. Normally I manage to only crash my Mac about once a year, and that was Monday (along with everything else that was going on Monday. After restarting the Mac, I again could not get Fusion to load from the VHD file. Again, I blew away the Vista config and started over. I left the Office 2007 install going and went home.

Tuesday I came in and first thing did a normal shut down of Vista and quit Fusion altogether. Then I did a normal restart on my Mac and restarted Fusion. Vista loaded just fine. *whew* Thought I was out of the woods. Then later in the day Tuesday I did something inside Vista that caused the Vista to lock up, and my only choice was to Force Quit Fusion to get back to a point to try to relaunch Vista. Guess what, Fusion wouldn't load the Vista HD. That was the last straw. I nuked the VHD for Vista/Fusion and went back to XP under Parallels, because I just had to get some work done.

Second, I'm not sure about how Fusion implements the Unity display. Granted, this may be more of a Vista thing than a Fusion thing, but according to the info on Fusion, their approach seems to be to try to completely hide the task bar in Unity mode and just use the Mac Dock for application icons. That may be well and good, and I do still get the Start button in the lower left corner of the screen, but what about the system tray icons? I have several tools that have a visible presence in the system tray, anti-virus software among them, that I regularly access from the system tray. Those icons were nowhere to be found in Fusion. In Parallels, because I get the entire Windows taskbar displayed above the Mac Dock, I get my system tray along with my application buttons, so I can access what I need. Unfortunately, Fusion/Vista kept crashing too often for me to get in and really look at that given everything else I needed to get done, so I can't say that it's not possible to get that, I just didn't see it on first glance.

I do plan on dong more testing with both Parallels and Fusion. Specifically, I'll be loading Vista into Parallels and see if I observe some of the quirks I noted in Fusion's installation of Vista. I'll also be loading XP under Fusion to see if some of the oddities are related to Fusion or to Vista. I know where I think it's going to be, but I'm reserving judgment until I can take more time with it.

In the meantime, to those who have asked me about Fusion and its viability as a production app, I have to issue a caution that right now I can't recommend it for a production solution like I can with Parallels. True, this is the first version, and VMWare has a long history of turning out quality product, so I know that Fusion will likely be a very good tool down the road, but I just can't recommend using it right now with Vista and expect to get any serious productivity out of it. Hopefully my experiences are in the minority and others have had better success with it, but being one who has to go on what I see with my own eyes, I'd say hold off a bit on Vista/Fusion. I expect that at some point in the future I'll be able to publish another post that gives the thumbs-up for Fusion/Vista, but that's not today.