Tagged: Windows 7 Toggle Comment Threads | Keyboard Shortcuts

  • Andrew T Schwab 10:19 pm on January 1, 2011 Permalink | Reply
    Tags: contig, defrag, drobo, eeebox, Mac OS X optimization, Power Defragger, scheduled defrag, Windows 7   

    Windows 7 Disk Defragging Your Drobo 

    Earlier today I was engaged in a short discussion on twitter with @mguhlin and @cbell619 about disk optimization in Mac OS X. I recall back in late 2003 when I was supporting a few hundred Macbooks, defragging disks was not something I usually concerned myself with. But if you’ve had your Mac a while and it’s running slow (like my sisters) you should follow the optimization directions in the post. Of course it didn’t hurt that the systems I had were re-imaged every summer which generally resets the clock on disk crud build up. That’s one nice thing about using imaging tools to manage large deployments.

    You’re probably asking, isn’t the title of this post Windows 7 Disk Defrag? Why yes. So after the twitter back and forth, I got curious about something and hopped on my recently purchased and setup eeebox Windows 7 system that I am using to front end my home Drobo (a more versatile Drobo Share, you might say) and checked the disk defrag status. Low and behold a scheduled task list came up instead.

    Odd, I thought, since I had not scheduled anything of the sort. Not like the old days when you had to create a .cmd file to run defrag.exe and manually set it to run via the Scheduler. Nope. Apparently Windows 7 automatically schedules defragging for you. It was even nice enough to schedule itself to defrag my three 2TB Drobo volumes. Nooooo!

    Needless to say, I turned it off on the drobo volumes. I had noticed some slow disk access while using the system. I am not sure if this was the cause or if the little eeebox is just slow. Time will tell.

    I know Windows needs to be defragged every now and again but I prefer to use the contig tool from Microsoft (formerly sysinternals) to do my defragging in Windows. I front end it with the free GUI Power Defragmenter utility to keep it simple.

    This is a good bit of information to know as I look forward to my School’s Windows 7 deployment next summer. Or maybe we’ll just go Mac and not have to worry about defragging disks at all.

     

    • Miguel Guhlin 7:55 am on January 3, 2011 Permalink | Reply

      Howdy! How does GUI Power Defragmenter compare to MyDefrag, the solution I use reglarly?

  • Andrew T Schwab 7:56 pm on October 27, 2009 Permalink | Reply
    Tags: FQDN, hostname, Network Bindings, OpenVPN, resolve, Untangle, Windows 7   

    Untangle OpenVPN client stops resolving FQDNs in Windows 7? 

    We use the OpenVPN module in the Untangle Open Source Network Gateway for remote access at our school district.   Everything had been working flawlessly for over a year until suddenly right before I was set to leave for a two day conference, I turned on my Windows 7 RC1 Acer Aspire One netbook, fired up the OpenVPN GUI client and then proceeded to fail at connecting to my remote clients using RDP.    I immediately checked my desktop Windows 7 RC1 install and found the same problem.  Long story short, somehow I had lost the ability to resolve my hostnames  to their correct private IP addresses while connected to the VPN.  The work around for my trip was to connect using IP addresses, which I duly noted before leaving.

    Upon my return I decided to troubleshoot the problem.  I was able to rule out a server side issue because 1) no settings had changed since the last time it worked and 2) my Hackintosh OS X desktop system running the OpenVPN client Viscosity worked just fine.  So to rule out my netbook as the culprit, I dusted off my old Dell Inspiron 6400 laptop, which is also running Windows 7 RC1, and tried the OpenVPN GUI client on it.  I got the same frustrating thing, the VPN client connected fine, I just couldn’t resolve my internal DNS names correctly.  I was wondering if this was a problem with the OpenVPN client I was running (2.1rc15) or what else could have possibly changed on both these systems to have this affect.  I decided to try my last instance of Windows 7 RC1 and so fired up Virtual Box on my Hackintosh, started OpenVPN GUI and was pleasantly surprised to connect right away with RDP using my internal hostnames (fully qualified, of course).

    Now I knew it was something with Windows 7 on both my desktop, netbook and laptop.  But what could be affecting all three?  Many moons ago, Windows used to have odd problems associated with NIC binding orders.  I happened to notice in the ipconfig dump on the Virtual Box host that the TAP-Win32 adapter was listed first and as this was the NIC with the correct DNS settings to resolve my internal hostnames it looked like something I should check on the other systems.  Sure enough the desktop, netbook and laptop all had the TAP NIC listed in second place when I ran ipconfig /all.  Ah ha!  A quick google search for how to change Windows 7 NIC bindings (not where it used to be) turned up this gem from dillonator:

    Get to the Network Connections page under the control panel. (If you’re looking at the Network and Sharing Center, click on Change Adapter Settings.) Now hit the “alt” key and you should see the menu pop up. Click on Advanced and you should know where you’re going from there

    I love the fact that you have to press the ALT key to see the advanced settings options.  After moving my TAP-Win32 adapter (Local Area Connection 3) on my desktop to the top of the Connections list I was once again able to RDP into my remote hosts using their fully qualified domain names (FQDN).

    NIC Bindings

    I have no idea why or how the binding orders on three of my four Windows 7 RC1 installations changed or why my Virtual Box host was unaffected but I am happily VPNing with OpenVPN once more.   Any ideas on how this might have happened, please leave a comment.  Thanks.

     

    • Martin 12:32 am on May 4, 2011 Permalink | Reply

      Strange, I’ve got the same problem but from an opposite angle: I do NOT distribute DNS servers in the OpenVPN configuration, I rely on the DNS config given from the DHCP server since all host information is public in my case.

      If I check the different adapters the Ethernet interface got DHCP config on it and the TAP interface has no DNS configuration.

      If I use nslookup I got proper answers.
      If I connect via ip addresses to both public services and the private ones that is routed through the tunnel all works fine but if use “ping” or any client that relies on the system resolver libraries then all DNS queries fails.

      I followed this guide and changed adapter priority but no luck.
      I worked around the problem by giving out DNS info on the TAP interface but it is annoying.

      The Linux and OSX boxes works fine whitout this trick.

c
Compose new post
j
Next post/Next comment
k
Previous post/Previous comment
r
Reply
e
Edit
o
Show/Hide comments
t
Go to top
l
Go to login
h
Show/Hide help
shift + esc
Cancel
%d bloggers like this: