Beyond Remote Desktop in SBS 2003

Hi gang - I am Harry Brelsford, the author of Windows Small Business Server 2003 Best PRactices and I am writing this today from Ocean Shores WA where I am fitting in a few vacation days before fall!

Each day - I like to post up a few pages from my book for your reading pleasure. I will do this unitl SBS 2008 ships and my new Small Business Server 2008 Blueprint book is on the shelves (around November 12th).

Today is a guest column from Frank Ohlhorst, well-known industry media guy now at Ziff-Davis. He speakes towards looking beyond RDP or remote desktop in SBS 2003. This concludes Chapter 8 of my book.

cheers....harrybbbbb

Harry Brelsford | CEO at SMB Nation | www.smbnation.com

Microsoft Small Business Specialist SBSC, MBA, MCSE, MCT, CNE, CLSE, CNP, MCP

And don't forget my SMB Nation 2008 fall conference is just five weeks aways in Seattle where we host a SBS 2008 and EBS 2008 luanch party!

Beyond Remote Desktop, the path to remote control.


Frank J. Ohlhorst


Small Business Server 2003 does a wonderful job of bundling remote access capabilities, but there are some drawbacks to how the product goes about that.


First off, there are some minimum requirements that must be met for those features to be viable, namely having Windows XP professional on the client PCs. That requirement leaves those using earlier operating systems out in the cold. Another limitation is that Microsoft’s Remote Desktop Connection uses Terminal Services, in other words it is a remote session, not a remote control solution. That prevents sharing the desktop with a remote user, a key requirement


for training or troubleshooting problems remotely. To overcome those limitations, integrators can turn to several third party


vendors for remote control packages, ranging from Symantec’s PCanywhere to hosted services such as GoToMyPC.com, but selecting one of those products requires an additional expense, which can be a hard sell, especially as SBS2003


includes the “remote desktop connection” feature. Savvy integrators can turn to a freeware/open source product called VNC


(Virtual Network Computing), which can be downloaded from www.realvnc.com. What makes VNC unique (beyond it being free) is that it is a multiplatform


product, in other words you can control a windows system from a linux system or solaris system or vice versa and VNC is quite compact and easy to use. VNC is a two part product, there is a server component and viewer component. The server component is installed on the system to be controlled, while the remote user uses the viewer component to take control of a remote system. VNC is a barebones product, and just offers basic remote control capabilities, with that in mind there are a few tricks integrators need to know to use the product. First off, VNC will not search for a system on the network, you must know the destination system’s IP address. Secondly, you will need access to the internal network to connect to a system. That can be a problem, but one easily solved by


Visit www.smbnation.com for additional SMB and SBS book, newsletter and conference resources.


just using the included VPN server that comes with SBS2003. Once you have established a VPN connection, just input the IP Address of the target PC into the VNC viewer application, enter a password and the remote control session becomes active.


While third party products may offer more robust features, such as file transfer and search features, integrators will find that VNC fits the bill for most remote support needs and at a price that can’t be beat.


Summary


I started the chapter emphasizing how important it is for mobile workers to have robust remote connectivity. SBS 2003 is positioned very well to support these individuals with services such as the amazing RWW and an impressive update to OWA. You were educated on other mobility matters such as VPN and Terminal Services. So now it’s your moment to fly away and join the ranks of the upwardly mobile!


See you next chapter.

Remote Desktop Protocol (RDP) in Windows Small Business Server 2003

Top of the morinng to ya! I am up and at 'em here in Seattle on the 520AM ferry enroute to the airport and some time in the San Francisco area...really starting to spend more time down there what with the hot technology sector (can u say SOMA?). So a quick post from Chapter 8 of my Windows Small Business Server 2003 Best Practices book - as u might know - I am posting up several pages per day from this book into the WILD for your reading pleasure. Why do I do this? Because I am a nice person! I will keep posting until SBS 2008 ships!

Today we explore the Remote desktop Protocol (RDP) in the mobility realm of SBS 2003.

cheers...harrybbbb

harry brelsford, smb nation's ceo www.smbnation.com

Microsoft Small Business Specialist (SBSC), MBA MCSE MCT CNE CLSE CNP

Did u know I host my big annual conference in early OCtober in Seattle!

###

Exploring RDP


Oops! I almost forgot some more stuff on RDP that I wanted to share (this has an advanced tone to it). RDP allows for separate virtual channels for carrying device communication and presentation data from the server, as well as encrypted client mouse and keyboard data. RDP uses its own video driver on the server-side to render display output by construction rendering information in network packets using the RDP protocol and sending them over the network to the client. On the client-side, it receives the rendering data and interprets them into the corresponding Win32 Graphic Display Interface (GDI) application programming interface (API) calls. On the input path, client mouse and keyboard messages are redirected from the client to the server. On the server-side, RDP uses its own virtual keyboard and mouse driver to receive these keyboard and mouse events.


Without encrypting the display protocol, it would be very easy to “sniff” the wire to discover the user’s passwords as they log on to the system. Allowing an administrator to log on using a non-encrypted protocol exposes the entire domain resources that are now vulnerable to hackers, especially if connecting over a public network without a VPN. It is both darn interesting and important to note


that protocols using “scrambling” to protect data are just as vulnerable to this


sort of attack as protocols that send data using clear text. The activity involved in sending and receiving data through the RDP stack is essentially the same as the seven-layer Open Standards Interconnection (OSI) model for the LANs on this planet. Data from an application or service to be transmitted is passed down through the protocol stacks, sectioned (sounds like a Ginsu knife commercial with slicing and dicing, eh?), directed to the channel (through MCS), encrypted, wrapped, framed, packaged onto the network protocol, and finally (really and truly) addressed and sent over the wire to the client. The returned data works the same way only in reverse, with the packet being stripped of its address, then unwrapped, decrypted, and so on (and on and on) until the data is presented to the application for use (Whew!). Key portions of the protocol stack modifications occur between the fourth and seventh layer, where the data is encrypted, wrapped and framed, directed to a channel and prioritized.


Lastly, every version of RDP uses RSA Security’s RC4 cipher, a stream cipher


designed to efficiently encrypt small amounts of varying data size. RC4 is designed for secure communications over networks and is also used in protocols such as SSL, which encrypts traffic to and from secure Web sites. By default, Windows XP Remote Desktop and Windows Server 2003 Remote Desktop and Terminal Services use high (128-bit) encryption to encrypt most data transmissions in both the client-to-server direction and the server-to-client direction.


BEST PRACTICE: Don’t forget the 128-bit encryption point raised here.


It is frequently brought up in technology conversations about SBS.