Monday, November 30, 2009

Open-Source Hardware?

As per this Wall Street Journal article, a company named Arduino has create a small microcontroller board, the schematics of which are freely available online. The two-man Italian company has gone from selling 34,000 of the $30 microcontrollers last year to a forecasted 60,000 microcontrollers this year. Other open source hardware projects of note include Chumby and Bug.

Personally, I wonder what the open-source hardware scene will really accomplish over time. Will it flourish as much as open-source software? Will it create as much innovation and competition as open-source software? Not being a hardware engineer, I can't speak with any authority. However, I doubt very highly that it will come close to the effects that open-source software has had on the world. Anyone can install software, however not just anyone can take advantage of circuit board schematics. The pool of potential project creators and contributors is drastically smaller. However the pool of potential consumers of products based on open-source hardware could conceivably be larger than that of open-source software. Interesting points to ponder.

Does anyone have experience with the open-source hardware "movement"? Any thoughts on the subject would be appreciated.

Saturday, November 28, 2009

A Macintosh is a Mac, not a MAC!!

If you are referrring to Macintosh computers in written word and truncate the brand name to "Mac", please refrain from capitalizing the three letters. "Mac" is simply a nickname, not an acronym. If you type MAC my brain jits it as Media Access Control, and that makes no sense when you say "I just bought a new MAC."

If anyone out there uses the capitalized "MAC" when referring to Macintosh computers, please explain it to me. I believe this is a fairly recent phenomena as I never recall seeing this behavior in the mid and late nineties when I was much more heavily involved in that brand.

Rant over. These aren't the droids you're looking for. You can go about your business.

Friday, November 27, 2009

List of Network Inventorying Software (Update Revision 2)

This thread over at Security-Forums.com sparked me to create a post where I can list the various IT asset inventorying software that I'm aware of.

Total Network Inventory
Manage Engine (Has multiple tools that could be in this category)
SpiceWorks
Network Inventory Advisor
LANrev
OCS Inventory (Would have been funnier if it was named "OCD Inventory". Commentor Matt recommends using GLPI as an interface for the poorly designed (as of this writing in November 2009) OCS interface. )
Open-AudIT
i-doit (Open and pro versions available. Is it disconcerting to anyone else what the product name turns into when you simply swap the "i" and "o"?)
Lansweeper (Recommended by commenter Chris. Windows only freeware.)

Please contribute if you know of other similar software! Close-source or open-source, it makes no difference.

Tuesday, November 24, 2009

How to send mail via Telnet

I've seen a number of tutorials on how to send email using a Telnet session, but the one over at wikiHow.com is the bee's knees. I post the link here as a memory aid, but hope it can help you as well:

http://www.wikihow.com/Send-Email-Using-Telnet

Friday, November 20, 2009

OpenDNS interferes with Outlook Anywhere

My Problem:
In an office using OpenDNS for name resolution, Outlook Anywhere retrieves an SSL certificate from OpenDNS rather than searching for and using the SSL certificate installed on your Exchange serve.


My Solution:
Use conditional forwarding for your SMTP domain in your internal DNS server to divert DNS queries for your SMTP domain away from OpenDNS.


The Long Story:
One of my users reported seeing a certificate error after I switched my SBS 2008 machine from using root hints to OpenDNS servers. Strangely, I did not have those errors when I used my offsite laptop which was also using OpenDNS servers. To attempt to reproduce the error, I connected to the network with a VPN and changed my DNS server to point to the SBS 2008 server. Sure enough, I got a certificate error.



When I clicked "View Certificate", I saw that I was somehow picking up an OpenDNS cert.




I reasoned that the problem was due to Outlook 2007's hard-coded behavior of attempting to connect to it's list of autodiscover subdomains such as autodiscover.SMTP-domain.com before finally settling on the domain's SRV record. Since we're using OpenDNS, the service tries to be helpful and returns a response when it sees we've requested a domain that does not exist (the IP returned for autodicsover.my-SMTP-domain.com is 208.69.36.132 which is an opendns IP)


Once again, I found it strange that if I use OpenDNS servers directly on my laptop I did not get that IP returned and Outlook Anywhere worked perfectly. I assumed it hadto do with the office having an OpenDNS account tied to that office IP whereas my laptop was not behind an IP address that had a OpenDNS accout. I did not create an OpenDNS account for my IP to see if the problems would suddenly start for me at home.


I logged into the office's free OpenDNS account but did not see any option to prevent a domain or subdomain from being resolved. I found it rather funny... I actually wanted OpenDNS to stop resolving DNS.


Several options presented themselves to me.




  1. Create a split DNS zone on the SBS server that made it authoritative for our public SMTP domain. This split DNS setup is fairly common, but requires you to manually maintain DNS entries that you create in your public zone in your private zone as well. Split DNS would casuse all clients in the building to receive a definitive resolution failure when requesting the autodiscover.my-SMTP-domain.com.
  2. Use conditional forwarders to forward queries for our domain to DNS servers other than OpenDNS's.
  3. Figure out a way to prevent Outlook from querying for the nonexistant domains.
Option 1 seemed viable, and I actually tried it half-heartedly. The added complexity scared me away from it and I ended up deleting the zone. Conditional forwarders won out after the thought of tweaking clients manually for anyone who ever used out email server from within the building made me break out in a rash.


I simply created a conditional forwarder that used our ISP's DNS servers for any query for our public domain name. That did the trick. Incidentally, I had attempted to put in the actually authoritative name servers as targets for the forwarder, but for some reason the targets would not resolve queries. Not willing to burn any more daylight on this problem, I settled for the ISP's DNS servers and all was well in the land.




P.S. I've also heard that the practice of returning helpful hints for non-resolving domain names that some ISPs do will also cause problems. I haven't had to deal with that yet and hope I never do.

Wednesday, November 18, 2009

List of Outlook Anywhere autodiscover DNS query attempts

This is a list of the various DNS queries that Outlook Anywhere clients will attempt to make before finally searching out a SRV record in the domain. This is taken directly from Microsoft KB940881. I reprint it here because I've already spent an embarrassing amount of time searching for this article after I forgot where I documented it. Hopefully I'll never forget again.



The succession of autodiscover attempts done by an Outlook 2007 SP1 client is now thus:

  1. Autodiscover posts to https://contoso.com/Autodiscover/Autodiscover.xml. This fails.
  2. Autodiscover posts to https://autodiscover.contoso.com/Autodiscover/Autodiscover.xml. This fails.
  3. Autodiscover performs the following redirect check:
    GET http://autodiscover.contoso.com/Autodiscover/Autodiscover.xml
    This fails.
  4. Autodiscover uses DNS SRV lookup for _autodiscover._tcp.contoso.com, and then "mail.contoso.com" is returned.
  5. Outlook asks permission from the user to continue with Autodiscover to post to https://mail.contoso.com/autodiscover/autodiscover.xml.
  6. Autodiscover's POST request is successfully posted to https://mail.contoso.com/autodiscover/autodiscover.xml.

Monday, November 16, 2009

Autodiscover clients are bringing back a strange certificate

The Problem:
Outlook Anywhere clients are returning a strange certificate (possibly from Plesk or cPanel) when attempting to connect to your SBS 2008 machine running Exchange 2007 using your public domain name.


The Solution:
Check your domain's DNS settings to see if you have a * record that handles all queries for subdomains that don't explicitly exist. For example *.mydomain.com. Remove it if it exists.


The Long Story:
Outlook Anywhere Queries several subdomains of your main SMTP domain looking for the autoconfiguration information. After the queries for domains like autoconfigure.my-SMTP-domain.com fail, then Outlook will query for a SRV record. SBS 2008 relies on a SRV record to point the Outlook Anywhere clients to the proper URL using the proper hostname that was registered in your SSL cert.

My clients were returning a certificate error with a host of problems.




After some heart palpitations in which I fretted that I had munged the certificate creation process somehow, I clicked "View Certificate" and found something puzzling:




The certificate was issued to Plesk! Plesk is the control panel that our domain is managed with. Somehow or another, Outlook was getting sent to something on our domain that was returning our control panel's certificate.

I tried some things, and then realized that I could type any nonsense gibberish as a subdomain of my main domain and be sent to our website. That caused a few minutes of childish fun as I typed silly subdomains in just to see them successfully bring up the organization's web site. That still didn't clue me in to the real problem though... because I'm a nublet and was not aware of DNS * records. After some sleuthing I happened to come across a forum that mentioned a "*" record which jogged my memory. I had actually seen a * record in our DNS control panel and hadn't thought much about it.

I quickly deleted the * record from our DNS control panel and after DNS propagated, Outlook Anywhere worked for my clients.

Personally, I think Outlook's requirement that DNS resolution fails for certain subdomains before it seeks out the SRV record is a bit flakey and error prone. In fact, you will see exactly why that might cause grief for some people that use OpenDNS or even certain ISPs in a post later this week...


The succession of autodiscover attempts done by an Outlook 2007 SP1 client is now thus:
  1. Autodiscover posts to https://contoso.com/Autodiscover/Autodiscover.xml. This fails.
  2. Autodiscover posts to https://autodiscover.contoso.com/Autodiscover/Autodiscover.xml. This fails.
  3. Autodiscover performs the following redirect check:


    GET http://autodiscover.contoso.com/Autodiscover/Autodiscover.xml
    This fails.


  4. Autodiscover uses DNS SRV lookup for _autodiscover._tcp.contoso.com, and then "mail.contoso.com" is returned.
  5. Outlook asks permission from the user to continue with Autodiscover to post to https://mail.contoso.com/autodiscover/autodiscover.xml.
  6. Autodiscover's POST request is successfully posted to https://mail.contoso.com/autodiscover/autodiscover.xml.

Thursday, November 12, 2009

Google Dashboard; more convenience than transparency

Some news headlines are touting Google Dashboard as a step towards transparency concerning the data that Google is collecting on you. After some research on the product (including using it for myself), it seems to be nothing more than a simple web page that lists all of the Google products that your account has activated with links to configuration pages for those products as well as some summary information.


Open Boston Media has a good review of the product that seems to put things in perfect context. This is certainly a convenience, but hardly worth labeling "transparency". As some have pointed out, this seems more like conditioning people for a single-sign-on experience which will either encourage people to use more of Google's existing services or be more likely to opt in for future services (or probably both).


Nonetheless, it can be useful for people who use a Google account to see what is publicly visible. Check it out for yourself and you just might discover that more about you was available than you first thought.

Wednesday, November 11, 2009

VMWare View 4 touted as "Disruptive, Game-Changing"; Uhhh... ever heard of Terminal Services?




Accorind to this ChannelInsider.com article, VMWare View 4 "could revolutionize how IT infrastructure is deployed today." Yet reading on, it seems to simply be another way of deploying a desktop computing experience to thin clients or home users' PCs ala Terminal Services or Citrix XenApp (née MetaFrame Server, née Presentation Server). The only difference being that View 4 would be based on virtual machines rather than different interactive sessions on the same server. Is that difference enough to call this "revolutionary"? I'm not hugely familiar with TS or Citrix products, but this seems to be pure, unadulterated hype. Cool hype... but hype nonetheless. 


As always, I'm eager to be proven wrong. Anyone want to step up and school me?


P.S. Not that I'm complaining about good hype for VMWare. Anything that raises the price of my VMW stock makes me smile. =)

Monday, November 9, 2009

Updated! Appending Whitelisted Domains to Exchange 2007's BypassedSenderDomain variable

My Problem:
I added a few domains to Exchange 2007's domain white list via the Exchange Management Shell using the cmdlet, Set-ContentFilterConfig -bypassedSenderDomains domain1.tld,domain2.tld. However, running the same command with domain3 as a variable will overwrite domain1.tld and domain2.tld. I needed to add domain3.tld to the existing whitelisted domains.

The Solution:
Nov 11, 2009 Update: Thanks to a tip in the comments section from one of my readers ( ::waves at Sharon:: ), I now use Glen Scales's PowerShell script that creates a simple GUI interface which allows you to update both the bypassedSenders and the bypassedSenderDomains list.







Before that GUI script, I would dump the existing contents of the bypassedSenderDomains variable to a new variable, add information to the new variable and then run Set-ContentFilterConfig using the newly modified variable:
$varWhitelist = (get-contentFilterConfig).bypassedSenderDomains
$varWhitelist.add("domain3.tld")
Set-ContentFilterConfig -bypassedSenderDomains $varWhitelist
There! It's so simple... or, not?



Etcetera:
As an addendum to this post, I have a complaint to lodge. Firstly, I don't mind a CLI/shell. I like PowerShell. I feel ashamed that I'm such a GUIfied Windows admin and sincerely want to get proficient with the command line, preferably PowerShell. However, the fact that certain functions in Exchange can only be done via the Management Shell and not the Console confutes me. Especially since the Console was touted as being built 100% on PowerShell.

Would someone in Microsoft's development department have their head melt like that guy at the end of Raiders of the Lost Ark if they added a simple GUI interface for the whitelisted domains feature? This seems like such a oft-used feature that it makes no sense to me to hide it in the shell. That's like taking something as commonplace to use as configuring your desktop picture and hiding it in a command line interface while leaving other similar options such as resolution and desktop icons in the GUI interface.

Furthermore, adding new domains shouldn't take three lines of script to do. I'm sure I could cram it on one line, but it's still three separate expressions. What's up with that? Maybe I'm just a whiny Windows admin.

Tuesday, November 3, 2009

Adding an RDNS record for a SBS 2008 environment

My Situation:
I was reading about the various kinds of DNS records needed for email to flow properly in an SBS 2008 environment and decided to create a simple RDNS record for mail server. My confusion came when I wasn't sure if the RDNS record should contain the name of the server as seen on the local network or as seen from  public DNS.

The Solution:
When creating an RDNS record, the hostname should match both the external A record for the IP where email exits your network as well as the FQDN that your MTA presents to SMTP servers. Most SBS 2008 admins will use remote for the external hostname A record and thus the RDNS record that they create should resolve to that same IP address. The FQDN in the internet send connector should be "remote.yourdomain.TLD"

The Long Story:
When creating a RDNS record, you need to supply the name of the server that is seen in Exchange 2007's send connector. However, when you use the Exchange Management Shell cmdlet "get-sendconnector | select name" you get a different name than if you look at the "specify the FQDN this connector will provide in response to HELO or EHLO" (that can be found by going to the Exchange Management Console >> Organization Configuration >> Hub Transport >> Send Connectors Tab >> right click the Windows SBS Internet Send [server name] connector and select properties >> General Tab)

The cmdlet returns the local DNS name of the Exchange server but the Send Connector properties box shows the external DNS name of the server; remote.compayname.com.

Questions started to arise in my head when I arealied that I've seen email headers stamped with the local DNS names of the email server and not the public DNS names. I wondered if I needed to create an RDNS record using the internal name of the server which would require me to create an A record in the public DNS zone named with the same name or if I shuold just create the RDNS record to point to the already existing "remote" A record.

After some research (the specific documents that I found were not recorded so I can't give links here; I'm a bad, bad researcher =( ), I discovered that the proper configuration does not include the name of the server on your local network in any way.

Monday, November 2, 2009

APC creates unobtrusive equipment racks that look like furniture.

Plenty of admins/consultants have to deal with small offices and branch offices that need a server or three, a firewall and maybe some switches. But where to put them? Usually those devices end up being bunkmates with mops and 5-gallon containers of Janitor in a Drum. However, APC has created their NetShelter CX series that  looks like an unobtrusive pieces of office cabinetry.




I have two concerns however:

  1. What about airflow? I see that the back is a screen but is there sufficient room on the front for intake? Being that it's produced by APC, I would give them the benefit of the doubt that they would take that into consideration.
  2. What about cooling? Does this thing trap heat more than a normal server rack would? That faux wood paneling must surely be more of a heat trap than the simple aluminum sides real server racks have. A subpoint of this issue is: Would it make people take the need for proper A/C flow on the unit even less seriously than people already do? Does making it look like a piece of furniture encourage equipment to be placed out in the open office where dust and heat roam unchecked??
Nonetheless, I'll look into one of these devices if the need for one at a small office rises.