• SharePoint Development with CloudShare Part 1
• SharePoint Development with CloudShare Part 2

In the last post, I talked briefly about the CloudShare service, in this post I’ll discuss in more detail about the practicalities of connecting and using a CloudShare subscription as a SharePoint developer, and this post has pictures 🙂

Getting Connected.

After you’ve logged in you can view your environment;

This shows the environments set up in your account and allows you to create more environments, clicking View Environment will take you to the environment page;

From here you can edit your environment, add hardware, add more virtual machines etc and you can also initiate a connection to the virtual machine.

Session Timeout.

One thing to be aware of is that your environment and machines will automatically suspend after 60 minutes, thats not 60 minutes of inactivity it’s really 60 actual minutes. After this time, the virtual machines in your environment will suspend and when this happens you’ll have to Resume them just like you would with a local virtual machine, and you can do this from the environment screen shown.

You can delay the Auto Suspend feature for upto 3 hours by clicking on the Extend link, and you also have the option to turn off the auto suspend feature – but for this you have to pay and it isn’t cheap, so for an independent contractor it’s probably not an option.

Having said all this, the CloudShare browser interface does a good job of informing you that your session is about to expire (see below) so you can always postpone the event during the course of your working day.

Connecting using Web Access.

Web Access allows you to connect to your CloudShare SharePoint environment using just the browser without having to open a virtual machine console or RDP session. Basically it’s like browsing to any other SharePoint site, to use web access click on the Web Access link at the bottom of your virtual machine window shown in the environment screen;

After you click the link, a new browser window or tab will open and you have to authenticate yourself, all familiar stuff. After authentication you’ll see the that the site collection at the root of the default port 80 web application is displayed.

This can be a good option for co-workers or clients to access your environment to explore POC’s or other features you’ve developed.

Connecting using the Virtual Machine Console.

The Virtual Machine console is literally a console onto the VM session in a browser, and as you can see there are various controls enabling you to interact your the virtual machine. Using this option can be useful if you want to reboot the VM as you will not be disconnected and can monitor the reboot process, however for day to day use this has limited value.

Connecting using the CloudShare RDP Plugin.

Next up is the browser based RDP connection, from the window shown above you can click on the “RDP” link and this will launch an RDP client in your browser (a plugin from CloudShare will be offered for download and install).

This is a lot more functional and you can change the virtual machine screen resolution to suit.

From both these connections options you can also;

• Disable and Enable File Sharing – this makes your local hard drives available to your virtual machine.
• Enable and Disable CloudShare’s new CloudFolders feature, using the Mount/UnMount links – CloudFolders allows you to upload files to an FTP location and after clicking the Mount link, that FTP location is made available to your virtual machine as a shared drive.
• Switch to Full Screen RDP.

Connecting using Full SCreen RDP.

Full screen RDP is perhaps the most useful as it loads a full screen RDP session (launched from the browser) again using a plugin from CloudShare. This experience is almost identical to using an external RDP client.

Click on the Fullscreen RDP link to launch.

Connecting using an External RDP Client.

To connect using an external RDP client you need the connection details, or host name, and this is available from your Environment page within the details window for a particular machine, click on More Details link;

Copy the External Address and paste it into your RDP client and connect using the credentials also shown on this page.

Note: During my experience with CloudShare to date, I’ve noticed that the External Address changes each time you resume your environment.

I found that using an external RDP client wasn’t really that great, there was a certain amount of lag when using the mouse or moving around with the keyboard and slower than normal screen refresh was noticable, now it wasn’t bad and it is certainly usable this way, but right now I’m preferring to use the browser based full screen RDP connection option.

One thing is, that I was using a very large screen size and this undoubtedly contributes to the percieved lag, as testing at smaller screen sizes improves this.

Connecting using an Mac.

What about using CloudShare with a Mac, again this isn’t a problem. You can login to your CloudShare account on your Mac (ignore the browser/OS warnings) and resume your environment. Then connect using a Mac RDP client, Coord or the RDC Client from Microsoft are good options.

Connecting using an iPad.

If all you want to do in your CloudShare virtual machine is point and click configuration, with some typing, you can connect using an iPad. Again, as with the Mac, login to your account using Safari and resume your environment.

Then connect using an RDP application downloaded to your iPad, Desktop Connect is one I’ve used and is feature rich.

Why CloudShare.

Now the question is, why would you use something like CloudShare, an environment in the cloud?

There are many good reasons, and CloudShare talks about many of these on its website, not least of which is the ability to hive off independent snapshots of an enviroment and make it available to co-workers or clients for them to play with, this alone is quite an attractive feature.

My reasons include;

1. The ability to build a fully functional SharePoint environment for development and/or testing in minutes.
2. Access to my environment from anywhere, on pretty any device (certainly on the devices I own).
3. I don’t have to carry around external harddrives with my VM’s on.
4. I can run up say a MOSS VM on my MacBook, and from that, use my 2010 environment in the cloud and flip between the two – certainly much more efficient than pausing/suspending a VM each time I need to flip between them.
5. Co-workers can access my VM directly, or can access a hived off snapshot of it.