In this continuing series I’ve covered the basics of setting up a good system from a “fit and finish” perspective so you are ready to go. I harped on some things that a lot of people don’t think about – clock / timezone, preparing your command prompts, cleaning up the clutter – all these things if left untouched will get in the way of your Demo storytelling. I followed that post up with a simple tool that is difficult to master – ZoomIt for your graphical environments.
Note: some have suggested I use the built in magnifying feature of Windows. Good point – but I find it lacks two things:
- It requires the Desktop Interface which is something I wouldn’t load on a server system.
- It lacks the ability to highlight areas of the screen with drawing or typing that ZoomIt provides.
To each their own – so long as you magnify the screen and keep movement to a minimum or else it becomes distracting.
Ultimately what we are talking about here is visibility
What about more complex demos that require multiple machines to be “output” the display to the screen? Obviously you can either remotely connect from a single system to a bunch of servers someplace or you can run with a server OS installed and virtualize the required systems in the room with you.
I tend to go with the second option where possible as you need less of a backup if internet connectivity is down. We’ll talk about “backup” to demos in a future post, for now let’s discuss the local server running a virtualization solution.
You basically have two options:
- use a “viewer” that can show you the “window” into the virtual guest, regardless of what guest OS it is.
- use remote connectivity like Remote Desktop Client to remote into the Guest VM (provided it is running windows).
Each solution requires some consideration and setup / prep to work correctly. My main advice – Remember the golden rule: Set your Resolution correctly on the Host as well as within EACH guest you will be showing. Slider bars are your enemy!
Because this is once again visual – here’s a quick video on how I approach selecting either the Viewer option or RemoteDesktop option for my demos.
Use the Built In Viewer:
- If you require a full window of restarts / reboots or if your guest OS is NON Windows.
- If you don’t mind opening each instance of the viewer for warming up the demo.
- If you close a VMGuest accidentally – you will need to launch Hyper-V manager and open the guest – no quick access.
- you don’t require more then basic copy and paste between Host and VMGuest
Use Remote Desktop Services with “Internal networks”
- If you don’t require full windows restarts.
- if you are running Windows Clients and want a richer connection experience (graphically optimized)
- prefer pinning and desktop icons to launch / re-launch systems quickly
- If you like to share files and services between Host and VMGuest – you can use “internal network” for connectivity.
It should be noted that you can also combine the two or use the “Internal Network” option with the Viewer as well. This gets you connectivity into the virtual switch and therefore allows your Host system to interact with all the VMGuests as required for setup / running of the demo.
What’s the right setup for you? Do you approach this differently for remotely managing systems and delivering your demo?
By the way: Feel free to give me some feedback to let me know if these posts are useful and if you have any specific questions around Demo delivery.
3 thoughts on “How To: Deliver Impactful Demos. Part 3 – Showing the Goods”
Dont forget that Windows 8 now has the Hyper-V client built in with virtual networking too. Have used this with great success for demos
You are correct sir. I was demoing this from my server box at the time but the same functionality exists for Hyper-V on Windows 8 client as well.
Comments are closed.