« July 2006 | Main | September 2006 »

August 30, 2006

Excellent overview of memory technologies

I remember the good old days of buying RAM, where the only two parameters were:

Those days are long gone.

Every time I have to spec memory for a server, I start to wallow in all the various attributes: DDR, ECC, Registered, PC1600, Dual-Ranked, etc. and even when looking at a full list of required specs, there's always the fear that I'm somehow missing a parameter that matters.

For instance: I once bought a stack of RAM upgrades for some Dell Optiplex workstations, but found that only DIMMs with chips on both sides were supported, not DIMMs with chips on only one side. Huh? I assume this has something to do with rank or bank, but they flat-out did not work. This was not listed anywhere in the specs for the RAM, and it contributes to this "I don't know how to order RAM" mentality.

While researching this today, I ran across an outstanding Flash presentation from Corsair that covers almost all of this. It's quite technical but doesn't require a BSEE to follow, and it's by far the most informative reference I've ever seen.

I learned, for one thing, what "Registered" memory is, and it made perfect sense. In unregistered RAM, the address lines from the memory controller go to each individual chip on each DIMM, and this can be 4, 8, or even 32 chips on a single stick. As more DIMMs are added, this presents a growing electrical load on the output of the memory controllers: how can the memory controller drive all those inputs?

By adding a register - kind of like a buffer - at the edge of the DIMM, the memory controller sees one load per DIMM, not 4 or 8 or more, and this allows for much electrically cleaner address signals.

They even covered how to read a timing spec such as 2.5-3-3-7-1T, and how it's even possible that half a clock can be involved (in DDR RAM, data is transferred on the both the rising and falling edges of the clock).

It's just an outstanding presentation:

Corsair - Memory Basics

The only real missing area is a discussion on single- versus dual- ranked memory and the cost/performance tradeoffs involved. I think this presentation is slightly dated, so this area of ranking (not banking!) may not have settled down yet.

Posted by steve at 07:52 AM | Comments (0)

August 03, 2006

Gotcha with Outlook 2003 with RPC-over-HTTPS

One of this nicest features of Outlook 2003 is that it can "phone home" to the Exchange server using not only the normal NETBIOS protocols, but it can also proxy this over a secure web connection. This is ideal for remote users who need the full-strength Outlook integration (as opposed to the almost-Outlook of OWA), all without the problems associated with a VPN.

It's just a great mechanism, there there is a lot of good guidance out there. My favorite is Troubleshooting RPC over HTTPS by fellow MVP Rodney Buike, but I've found a corner case which caused me to waste a maddening amount of time.

My environment is an SBS2003 machine hosted at a data center, and 100% of the real users being remote, not part of the domain, and with no access to any of the NETBIOS-ish protocols that Outlook normally uses to talk with Exchange.

Furthermore, the machine's real hostname uses the .lan extension (others typically use .local), as we didn't want to use our real company domain because Windows would then want to "own" it. So by calling it sbs.company.lan, Active Directory wouldn't interfere with the rest of our DNS.

The gotcha is during initial setup of the mailbox, you must enter the internal hostname of the Exchange server, and this will fail the first time. The remote users are not in the same data center, have no access to the .company.lan nameservers, so of course name lookup will fail. This is expected!

Simply clicking through these error messages allows you to get to the [More Settings] button to configure the Exchange Proxy Settings in the Connections tab. At this point you'll enter the external name of the machine (https://sbs.company.com) to allow it to make the actual TCP connection to the IIS-based proxy.

Once the proxy is configured, it becomes the exclusive communications channel for this session to Exchange. Then later, when Outlook tries to connect, it passes the internal name (found in the initial setup screen) over the protocol exchanged via the proxy.

My mistake was using the external name (the hostname of the proxy) where Outlook wanted the name of the Exchange server. Even though the proxy was indeed making the proper SSL connection, the use of the wrong name passed over the protocol failed the connection.

My familiarity with DNS was leading me astray: "that name can't resolve" got me to use the external hostname, and it always failed.

It turns out that SBS users have a little bit of extra help configuring this: the RWW (Remote Web Workplace) default website on the SBS server itself. When visiting the site (http://sbs.example.com/Remote) and logging in, there is a Configure Outlook via the Internet link in the box on the left; it provides instructions filled in with the particular parameters required.

So we learned something here, though I don't think I appreciate the difficulty of debugging this.

Posted by steve at 09:30 AM | Comments (1)

August 01, 2006

New Tech Tip: Remote Access for SBS2003

I have quite a few customers who run SBS (Microsoft Small Business Server) 2003, and everybody wants remote access of one kind or another. Email, files, their desktop - everybody wants in from the outside.

The easy part is getting them access - the hard part is making sure it's secure, and it got overwhelming quickly to see how many choices and variation there were.

So I undertook a comprehensive survey of the available choices and produced another Tech Tip which looks to have pretty wide coverage of the technology in question. In addition to the background and details, I include a set of Pro and Con lists for each one, which hopefully will guide somebody into making the proper tradeoffs.

It's mainly intended for SBS2003 users — SBS has some special features not available elsewhere — but should nevertheless still be useful to most of the Windows Server variants.

Posted by steve at 10:07 AM