One of the questions I have been hearing often involves my very first blog post on this site -- "What about the Blue Monster?"  The truth is, I haven't regretted that tattoo since I got it and now is no exception.  The Blue Monster is staying.  :)

Working at Microsoft has been the greatest experience of my life and I have no desire to forget about it.  And even if I don't get back into Microsoft right away (which is, by the way, my plan!), then I have a reminder that even outside of Microsoft, I need to do my best to change the world every single day.

I'm not sure how my lay-off affects my ability to blog here, but rather than risking a sudden loss of access, I have decided to start a new blog.  I'm planning on keeping it focused on technology, much like this one was (mostly), but who knows where it will go?  Update your bookmarks, RSS feeds, and stop by to say hello.

I realized (in my third draft of this post) that a lot of security items relate directly to "physical access."  Trying to include them all in one post would've made this quite long.  Instead, I'm going to break this up into several posts.  To get started, let me ask some questions relating to physical security:

1. What is the password policy in your organization?  Are you enforcing complex passwords?  Have you educated your users about the dangers of using a password containing dictionary words and/or personally identifiable information, such as birthdates, pet names, etc.?  Have you configured the "display logon screen on resume" functionality in the screensaver options?  Are you using two-factor authentication so that it takes more than a password to get in?
2. What is your policy on external devices?  Do users have the ability to connect an external device, such as a USB thumb drive, to their machines? 
3. Do you use encryption software on your hard drives?  If a hacker does get his/her hands on your laptop/desktop/server machine and remove the drive(s), can they access them? 

The point of this is not to frighten you, but to get you to think about security in a holistic way.  It's more than alarms and passwords -- it needs to be a comprehensive plan to cover all aspects of security in order to keep your data safe while allowing access to those who require it.

Watch for more posts on security-related topics.  In the meantime, think about potential holes in your current security scheme.

But, I have noticed that I often see President-elect Obama with a portable device of some sort in hand.  I didn't really wonder what it was until I saw an article discussing his device of choice.  What does he use?  A Blackberry.  You might wonder why I, an avid evangelist of Microsoft products, is blogging about our competitor's technology.  The reason for that is the rest of the article -- once Obama becomes President, he will be switching to an NSA-approved device running... you guessed it:  Windows Mobile.  The reason for this is the level of security needed to meet government regulations.  While some form of encryption is available on most handheld devices, the Windows Mobile device is up to the task of securing the communications of the leader of the free world.  As the old saying goes, "if it's good enough for him..."

And while this may seem like a light-hearted post, the truth is that security is something for which we all need to be responsible.  It comes down to a trade-off between business continuity and risk management.  The easiest way to secure your data is to simply not have any.  No data = no risk of any unauthorized people accessing it.  That, of course, is ludicrous.  Since we need information to keep our business moving, the task becomes how to secure that data so that only those who should have access do have access. 

Too often, when giving a presentation, I find that many people do not take security risks seriously.  They consider "hackers" to be only the worry of governments and multi-billion dollar enterprises.  This attitude could not be farther from the truth.  Unfortunately, many do not heed this warning until it is too late.  I know several businesses locally, for instance, that use unprotected wi-fi networks.  I know this because they are in range of public hotspots, such as coffee shops, which I frequent.  When connecting to the public network, I can clearly see the SSID of a local business attached to an unsecured wireless network.  Even a "secured" network does not really mean that your data is secure.  A wireless network running WEP, for instance, isn't really a safe network.  WEP, which stands for Wired Equivalent Privacy, is an old technology which can, according to Wikipedia, be cracked within minutes with readily available software.  Unfortunately, WEP is still being used to "secure" networks. 

If you want to know more about what you can do to protect your own systems from unauthorized access, I can help.  While I am not the NSA, I can offer some security best practices for you to follow.  Stay tuned for future blog posts relating to how to better protect yourself and your data from intruders.  You can also use the "tag cloud" on my blog page to find posts related to security simply by clicking "security" (as shown below). 

Now that you're thinking about security, want to know more about the specialized NSA-approved devices the President can use?  Read all about them here.

You can learn more about what's new in the beta here.  They've even got videos up showing the new features in Windows 7.

I'll be covering more about Windows 7 in future posts, but wanted to make sure you were aware of the beta as soon as I found out it was available!

Enjoy!

The official message can be found here.

Ok... I just looked through the archive for the Live Mesh distribution list (think e-mail group) and realized that I am not the first person to come up with this idea.  I didn't really think I was, but I did come up with it on my own.  ;)

Anyway, what we discovered is that Live Mesh is capable of syncing your Internet "favorites" across all of your machines, as well as providing you with access to those URLs from the Live Desktop.  This means if you have multiple computers you use to surf the Internet (as I do), then you can sync all of your favorites automatically so that every one of your computers has the same favorites folder!!! 

It's actually fairly straightforward and easy to do.  All you need to do is install Live Mesh.  On the first machine, go to your favorites folder, then move up one level (so that you see your favorites as a folder, rather than individual files -- see below). 

Right click on the folder and select "Add folder to Live Mesh."

You will see a menu that looks similar to this one (once you click the arrow next to "synchronization options"). 

Select the computers you wish to sync to, then click OK.  The folder is now a Live Mesh folder.  On the devices you've just synced the folder to, you will need to put the Mesh folder in the correct place.

By default, Live Mesh puts a blue Mesh folder shortcut on the desktop of the machines it is syncing to.  Double-click that shortcut and you will see a message similar to this one (except that it will be "favorites" instead of "downloads"). 

You can use the browse button to select the location of this folder.  Put it into your user folder (where your current favorites folder is located) replacing the current favorites folder.  (It's a good idea to make sure all of the favorites you want are located on the machine you started with, since the overwrite can (though shouldn't) erase favorites on your other machines).

That's it.  Your favorites will now sync across all of your devices, giving you the same list of IE favorites on each machine you've synced to.  You will also have your favorites available to you from your Live Desktop (which means from any machine with an Internet connection) provided you included your Live Desktop in your sync options.

Expanding beyond the horizons of the favorites folder, can you see the possibilities here?  Custom dictionaries, music, videos, draft documents, customized program settings...  all of these can be Meshed across your PCs, giving you the same experience from one machine to another, updating changes immediately!  It's going to be a busy Live Mesh weekend for me!  :)

Enjoy!

This is my Mesh Ring.  You can see I have three PCs connected to my Mesh Ring -- Jack, my home PC, DaniWoodHP, the machine I use for work, and Test Machine, which is an old PC that was lying around the office which I am using to demonstrate some of the features of Live Mesh.

Before I get too far into how it works, let's take a look at how to get it, set it up, etc.  Rather than me typing all of this, I've done a screencast below to outline the installation, setup, and features in Live Mesh.  Instead of spending the time writing a short novel (which is what I would have to do in order to tell you all about Mesh), I decided to make a screencast.  So, here you go.  You will need to have Microsoft Silverlight installed to watch this video.  Double clicking on the video will open it in full screen mode, which will make it a bit easier to see.  ;)  Here's a link to the video in case the embedded video doesn't work for you.

Just a couple things before I go:

1.  The whole reason I undertook this project was to explain a message my co-worker was seeing today with Mesh.  When connecting to a remote PC (that was sitting on his desk right next to his other machine), he was seeing a message (on the "remote" machine) asking him to deny/allow the connection.  This message appears if Mesh detects that someone is using the PC you are attempting to connect to.  The reason for this is that connecting remotely will, by default, blank the screen on the remote machine, kicking off the user currently using the machine.  If, for instance, you were trying to connect to your home PC and someone was using it at the time, they would have 30 seconds to click "Deny" on the connection screen.  If they don't click anything in that time (or if they click allow), then the connection will go through.  If Mesh does not detect that anyone is using the PC (it's locked, for instance), then there is no delay and the connection will happen immediately.

2.  In the screencast, I mention that you can use this to connect to other peoples' PC for remote connectivity and troubleshooting.  This is true, but only if that machine is running Live Mesh under YOUR credentials.  If, as an example, I wanted to connect to my Dad's machine remotely, I would have to ensure he was signed into Live Mesh using my Windows Live ID.  (You can't control machines that are logged in with others' credentials, even if they are sharing files with you.)  While I don't suggest giving out your Windows Live ID, you can certainly set up Mesh for them using your ID and selecting "Sign me in automatically."  This also gives you control over how they are sharing files and folders with you.  (This only applies to remote connectivity.  You can share files and folders with other people's PCs even if they are signed in with their own credentials.)

This gives you a good introduction to Live Mesh.  Play.  Explore.  Benefit.  Enjoy!

How Does it Work?

iSCSI requires the installation of a special piece of software, called an initiator, on the host machine.  This allows the host to accommodate incoming iSCSI commands.  Microsoft has released a free download for Server 2000 and Server 2003.  Server 2008 comes with the iSCSI initiator included out of the box.  The initiator, installed on the host, initiates and receives requests from the iSCSI target via the IP network. 

In Plain English, Please?

It sounds more complicated than it is.  The host machine (running the iSCSI initiator) is connected to your network.  It sends special network traffic to the target machine (where the iSCSI devices are installed) to access the storage devices.  The data being written to and read from the drive is encapsulated within that network traffic and sent back to the host machine.  In essence, it's like having a really, really long drive cable connected from your host machine to your target machine.  Since it all runs over TCP/IP (which is the same protocol used by most web traffic), there's no need to install specialized networking gear to make iSCSI work.

It Sounds Too Good to Be True!

Like a lot of innovative technology, this does sound too good to be true, which doesn't stop it from actually being true.  Considerations must be taken to ensure that the performance of your iSCSI SAN meets your needs and expectations.  While you don't need specialized networking hardware, you do want to use high-speed dedicated hardware for the SAN.  This means gigabit Ethernet cards in your target and host machines.  (This gigabit card should be in addition to the existing network card being used to access the public/internal networks.)  Having such a card dedicated to the SAN traffic will help you achieve optimal performance.  Isolating the SAN traffic onto a private network will also help boost your SAN's performance.  Dual processors are also recommended in all of your iSCSI hosts. 

Security is also a concern.  By default, no security protocol is in place for IP traffic, even that being carried over an iSCSI connection.  This is an obvious concern.  Fortunately, CHAP and IPSec can be used to maintain security of your data being transmitted.  CHAP is used as a negotiation between the host and target.  If the host and target both know the secret password, the connection is established.  If not, the connection is terminated.  This prevents unauthorized machines from accessing your data via a direct connection, but does not protect your encapsulated data while it is in transit.  For that, IPSec is required.  IPSec is a security method which can be implemented on your iSCSI network to encrypt the traffic as it flows from point A to point B, protecting it from people attempting to intercept it.

SAN and Clustering

Clustering servers requires that they have access to the same shared storage.  If we go back to the diagrams from the last post, we can see that centralized storage is an integral part of the clustering scenarios I outlined.

The SAN allows both clustered servers to access the data being written.  If the storage were local to one of the servers and that server failed...  you can see where that goes.  It renders your cluster ineffective.  Thus, centralized SAN storage becomes imperative to redundancy. 

You can find more information on iSCSI SAN solutions and how to set them up here.  Jose Barreto, member of the Storage Solutions Division, has some great blog posts on this subject, which begin here.

One of the concerns around creating a failover cluster in Windows is the need to use similar hardware for all of the nodes within the cluster.  (This is the Microsoft recommended method of creating a failover cluster.)  As my friend Jamie pointed out (after reading my last post -- he happened to be on vacation in the Dominican Republic at the time.  That's a pretty dedicated blog reader right there!), one of the biggest advantages of using clustering with virtualization is that virtual machines, by default, are "similar."  In fact, all of the machines created in Hyper-V have the same virtual hardware specs, regardless of what physical hardware the host OS is running on.  Thus, planning a virtual cluster eliminates the "similar hardware" requirement. 

One of the main concerns when building a failover cluster is, "Where do I store my files?"  Since a virtual machine is really just a file stored on a hard drive, it becomes important to consider not only where you will store data used by the machine, but where you will store the machine file itself.

There are a couple different ways to create virtual clusters, depending on your needs.  You can cluster virtual machines together to create a cluster of virtual machines or you can cluster physical hosts together to make a single virtual machine highly available.  Let's take a look at some diagrams to understand exactly what the differences are.

In this picture, we can see that two virtual machines are connected to a SAN (Storage Area Network).  The virtual machine files are stored locally on each of their respective physical hosts.  The data being used by the virtual machines (the data for applications running on the machines, for instance) is hosted on the shared SAN.  The two virtual machines are clustered together.  When one of the virtual machines fails, the other takes over, leveraging the data stored on the shared drive.  In this way, the applications running on the virtual machines are highly available. 

The second way to handle this scenario is shown in the following diagram.

In last week's post, I implied that clustering two physical machines together could potentially cause a problem, as the physical machines are monitored by the cluster, but not the virtual machines.  (Actually, I may have come out and said it, rather than implied it.)  The truth is, that's only partly true.  My goal was to help you understand the basics of clustering before getting down into the details.  It is possible to have a workable solution using clustered physical machines and virtual machine failover, as shown in the diagram above.  In this case, two physical servers are clustered together and are both connected to the SAN.  The virtual machine, in this case, is stored on the SAN, rather than on one of the physical machines' local drives.  The virtual machine is set, in the cluster management tool, to be a highly available "application."  Thus, if one of the physical machines fail, the other machine will automatically launch the shared virtual machine.

In a manual failover (such as for planned maintenance on the physical machines), the virtual machine will actually be saved, shut down, transferred, and started again -- all with one click in the cluster management console.  It is a quick process (the time it takes is dependent upon factors such as amount of virtual memory to be saved to disk) and allows the state of the virtual machine to be transferred from one host to the other.  In the event of an actual disaster (and an automated failover), the state would not be saved (as the physical hardware would've failed at this point) and the virtual machine would start clean (as if it had been rebooted) from the files on the shared SAN device.

Each of these scenarios has its benefits.  They are semi-interchangeable (they have functionality overlap), but as we dive further, you can see where one is more appropriate for certain situations.  Think, for instance, of licensing.  Which of the following scenarios do you think involves more Windows licenses?

Diagram A

Diagram B

In both scenarios, we have 6 highly available machines.  We are using virtualization to create the machines.  But as you can see, the results are completely different.  In Diagram A, we're looking at 8 instances of Windows Server and one cluster to manage.  In Diagram B, we have 14 instances of Windows Server running and 6 individual clusters to manage!  Clearly, Diagram A is the superior solution, right?  Not always.  Imagine, for instance, that we have two servers which have been removed from production duty as part of our virtualization consolidation.  These two servers are not remotely similar.  One is an AMD machine and the other is an Intel machine.  Both are capable of running Server 2008 and Hyper-V, but that's where the similarities end.  Are they going to be acceptable for solution A?  Maybe.  Remember, though, that similar hardware is important in a cluster.  Will it work anyway?  Maybe.  Is it supported?  Maybe not.  But, in the solution in Diagram B, we don't need them to be similar.  Those machines can be anything capable of running Server 2008 and Hyper-V.  As long as they each have enough memory and processing power for the virtual machines which will be hosted on them, they will work for scenario B. 

But, you mentioned licensing earlier.  Certainly, Diagram A represents the less expensive route from a licensing standpoint.

Ah.... you were paying attention!  Good.  I did mention licensing.  But, is Diagram A really less expensive?  Consider, for instance, that you really did free up two servers during your server consolidation to virtualization.  And suppose each of those servers is running Windows Server 2008 Datacenter edition...  that allows for unlimited virtual instances to be hosted.  Under those circumstances, licensing wouldn't enter into the picture at all.  Now, scenario A may be the costlier, as you may need to purchase a server to match one you have in order to create a supported cluster.

This is like a philosophical question - there is no "one truth."  In this case, several factors will dictate which of these solutions best meets your needs, taking all considerations into account.

Stay tuned for the next exciting episode!