Windows 8 recently hit RTM and became generally available to MSDN and TechNet subscribers in the last couple of weeks. If you run Windows 8 Enterprise, one new feature you gain is the ability to use Hyper-V. I personally was excited to try out this new feature since I have had issues with pretty much every other virtualization platform out there. I’m no virtualization expert by any means, but hopefully these tips will be useful for you if you want to try out SharePoint on Hyper-V.
If you are like me, you probably have a number of virtual machines already created that you don’t care to give up. In my case, I had a number of virtual machines from both VMWare and VirtualBox. I figured there had to be a way to convert them, but I have had bad luck with conversion tools in the past. However, Milton Goh (@miltongoh) pointed me to the Starwind Coverter. The tool is simple to use. Give it the path to your source file and tell it the output type (.vhd in this case), wait a while and you will have a new image that is ready to be mounted in Hyper-V. It leaves your old image in tact so you can continue to use it if necessary.
Once you are ready to take the Hyper-V plunge, you need to install that feature. Do this by going to Control Panel –> Programs –> Turn Windows features on or off. Check the box for Hyper-V and continue. After installation, you will be prompted for reboot.
One thing to note is that once you enable Hyper-V, VMWare Workstation will no longer function. When you attempt to start a VM in VMWare, it will display an error message stating that it cannot run with the Hyper-V feature added. Should you need to revert to VMware, you will need to remove the role and reboot.
Now we are ready to start configuring Hyper-V. First you need to start it. The easiest way to do that is to go to the start menu and type in the word “Hyper”.
Launch the application and you’ll see a screen like this one. In my case, I have already created a few virtual machines.
At this point, I recommend setting the default location for Virtual Hard Disk and Virtual Machines. Otherwise, it buries it in your personal user folder. You can do this by clicking on the Hyper-V Settings Action on the right. You can also change the default Mouse Release Key here (Ctrl+Alt+Left Arrow by default).
In order for your virtual machines to communicate with the outside world, you need to create a few Virtual Switches. To do this click on the Virtual Switch Manager Action. You will then see a screen like the one below. I have already created a couple and I will explain them shortly.
Depending on your configuration, you will probably need a few of these. There are three types. External switches allow your VM to communicate with the outside world using one of your computer’s network cards. Internal switches allow the host machine and guest machines to communicate with each other. Lastly, Private switches are used to allow virtual machines to communicate with each other (i.e.: with a domain controller running on another VM). At the minimum, I recommend an external and an internal to get you started. Let’s look at the settings for an external switch. Give it a descriptive name and then choose which network adapter it will use. If you have multiple network adapters (i.e.: wireless and Ethernet), you may want to create multiple external switches. Here is what the settings look like.
After you have created your switches, you are ready to begin creating a new virtual machine. Click on New –> Virtual Machine in the Actions pane to begin the process. Next, give your VM a name and you may also want to pick a different location to store the machine.
On the next screen, you can assign how much memory to allocate at startup. You can also opt to use Dynamic Memory which allows Hyper-V to allocate more memory as desired. We’ll look at this setting more once the machine is created.
You will then be prompted to configure networking. Here you can set the option for the first network adapter. However, after the machine is configured you will need to add more. In my case, I set the external network first.
Lastly, you specify the location of your newly converted virtual hard disk.
You can now finish and create your virtual machine. However, you still have more settings to change. Click on the virtual machine and then click on Settings Action. The first thing you need to do is add another Network Adapter for any of the other switches you created.
You’ll then want to adjust the dynamic memory range allocated to the virtual machine. Adjust this based upon your needs and hardware.
Lastly, I usually adjust the number of virtual processors. Typically I go with four. There is probably some official guidance on how to set this somewhere, but that’s what I run with.
Save your settings and you’re now ready to start your virtual machine. Click on your virtual machine and then click the Start action. If all goes well, your virtual machine will start. You can view what’s going on in the virtual machine by using the Connect action. This will show you the console of the virtual machine that you can work with. Once the machine boots, it will restart hardware detection since all of the virtual hardware is different. Once it boots up, you will want to install Integration Services. This makes your mouse work and does a bunch of things inside the guest so that Hyper-V knows what is going on. You can run the setup by clicking on Action –> Insert Integration Services Setup Disk in the console window. Run the installer and then reboot. Your virtual machine should now be able to connect to the network and mouse capture will work properly now.
As far as SharePoint goes, I have migrated both a SharePoint 2010 and SharePoint 2013 Preview image over and have had no issues. Once I did all of the hardware setup and rebooting, everything worked fine. I find that it runs quite fast though and “seems” to run better than VirtualBox and VMWare. However, that is completely subjective and I have no numbers to back it up. The machines seem to be find with the host operating system going to sleep and work just fine when resuming.
Compared to other virtualization platforms, Hyper-V does have a few small annoyances. The console window is quite limited. It only supports a few resolutions and copy / paste with it are quite painful. To get around that, I just use Remote Desktop for interacting with the virtual machine instead. To do that, you will need to set up that Internal network switch. There also isn’t a built-in host file system mount like in other virtualization platforms so you have to rely on network connections to transfer any files. Also, I have found that when switching physical networks, I have to release my IP address and renew it on the virtual machine. This applies mainly when going between work and home.
All in all, I am pretty happy with it. The resume / suspend times are quite good. I have had numerous issues in the past where sometimes it would take 30 minutes to resume a virtual machine on other platforms. This makes me quite happy that I haven’t experience that. Are you using Windows 8 Hyper-V with SharePoint yet? What are your experiences? Did I miss anything? Please, share your tips in the comments below.
Follow me on twitter @coreyroth
When it comes to development, the introduction of the application model overshadows many of the other new things happening in SharePoint 2013 development. I noticed one particular change as I was working on a new slide deck regarding the change to the default trust level of a web application. In SharePoint 2007 and SharePoint 2010, the Trust element was set to a value of WSS_Minimal. Effectively what this did was it meant that any DLL deployed to the web application bin folder was untrusted. This meant your code had to either run in the GAC (giving it full trust) or you had to specify Code Access Security (CAS) policies to enable partial trust. CAS policies were quite complicated and most SharePoint developers did not know how to implement them. However, in the 2007 days I was a big fan of them and got many developers started with this blog post and later with this post for SharePoint 2010.
In SharePoint 2013 Preview, this changes. The trust level is now set to Full.
</providers>
</siteMap>
<trust level="Full" originUrl="" legacyCasModel="true" />
<webParts>
<transformers>
According to the very little information I have found on the topic this is due to the fact that .NET 4.0 has a new CAS model. The legacyCasModel attribute is set to true to enable previously written code with CAS policies to still function. What this means is that code can now be deployed to the bin folder (which is faster) and it will have the same permissions as if deployed to the GAC. Now what this means from a security stand point is up for debate I am sure. However when Visual Studio 2010 came out everyone started deploying to the GAC any ways since it was just so much easier. In reality, it probably doesn’t affect things much in the scheme of things. Of course if you are developing sandboxed solutions or for the new app model this makes little difference to you. I still thought it was an interesting change.
NOTE: This post is build with Visual Studio 2012 RC and Preview 1 of the Office Developer Tools. See this post for an update with Preview 2 of the Office Developer Tools and the RTM version of SharePoint 2013.
I am extremely interested in the new SharePoint 2013 App model so I have been doing a lot with them lately. The latest thing I was trying was building a SharePoint-hosted Client Web Part. I have found that there is not a lot of information out there yet on how to use these so I wanted to share some of the things I ran into. This post on MSDN is good to help you get started with the setup of your app. Hopefully this info will help you get started. This post assumes you have installed Visual Studio 2012 RC as well as the SharePoint development tools.
After you open Visual Studio 2012 RC, create a new SharePoint app by choosing Office / SharePoint –> Apps –> App for SharePoint 2013.
You’ll then be prompted for the type of app as well as a name and deployment location. For the deployment location, you need to specify the URL to a site created with the Development Site template. I created a new site collection for this. I am not sure if it is required or not but I am fairly certain it is.
At this point, you’ll have a new SharePoint-hosted App project. Now, we just need to add the pieces that we need. However, first you need to understand a little bit about the ClientWebPart. This new type of web part is essentially two pieces: an elements.xml file and an .aspx page. The elements.xml file performs many of the same functions as a .webpart file, but it has different parameters. It’s main purpose is to specify the path to a .aspx page which it then loads in an IFRAME. Since it is an IFRAME, this page can actually be hosted anywhere: locally, on a remote web server, or in Azure. However, hosting it locally inside SharePoint is by far the simplest.
We’ll create the Client Web Part using the New Item menu:
When the Client Web Part is created, you’ll get an XML file that looks like this.
You can update the Client Web Part title, description, and size here. Note, that end users can’t change the size of the Client Web part once it’s deployed so set the value correctly here. Note the Content element. We need to update this value to the location of the associated page we are about to create. We need to specify the URL to the page associated with our ClientWebPart. To do this we make use of the ~appWebUrl token and then just specify the relative path Pages/HelloWorldClientWebPart.aspx. Here is what the entire XML looks like.
<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
<ClientWebPart Name="HelloWorldClientWebPart" Title="HelloWorldClientWebPart" Description="This is my awesome HelloWorldClientWebPart." DefaultWidth="300" DefaultHeight="200">
<!-- Content element identifies the location of the page that will render inside the client web part
Properties are referenced on the query string using the pattern _propertyName_
Example: Src="~appWebUrl/Pages/ClientWebPart1.aspx?Property1=_property1_" -->
<Content Type="html" Src="~appWebUrl/Pages/HelloWorldClientWebPart.aspx" />
<!-- Define properties in the Properties element
Remember to put Property Name on the Src attribute of the Content element above
<Properties>
<Property Name="property1" Type="string" WebBrowsable="true" WebDisplayName="First Property" WebDescription="Description 1" WebCategory="Custom Properties" DefaultValue="String Property" RequiresDesignerPermission="true" />
</Properties> -->
</ClientWebPart>
</Elements>
You can pass properties from the the user enters from ClientWebPart itself to the page here, but we’ll cover that in another post.
Now, we need to create the page that will be loaded in the IFRAME by the Client Web Part. For simplicity, I go with the same name as the Client Web part.
The default page looks like this.
It’s this part where I couldn’t find any details on how to proceed. You might be wondering if you need to do something to this page before it will work in a Client Web Part. The answer is “yes”. If you do try to deploy it as is, you’ll get the following error when trying to use the Client Web Part.
This content cannot be displayed in a frame.
Luckily, Saurabh Bhatia came through for me in the forums and helped me out. You need to include the AllowFraming tag in your page to allow it to render in an IFRAME. Everything else in the page needs to go with the exception of the reference to the WebPartPages tag. If you leave references to the master page or content place holders, you’ll receive a heap of JavaScript errors. Here’s what my complete page looks like.
<%@ Register Tagprefix="WebPartPages" Namespace="Microsoft.SharePoint.WebPartPages" Assembly="Microsoft.SharePoint, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
<WebPartPages:AllowFraming ID="AllowFraming1" runat="server" />
<div>Hello World Client Web Part!</div>
At this point, we are ready to deploy. You can do so by pressing F5 or choosing Build –> Deploy. This will package your app and after a moment, you’ll see your app listed.
This is a Client Web Part so you don’t need to click on your App here. Instead, go to the Home Page and then edit it. Pick a place on the page and then click on Insert in the ribbon. You’ll notice this looks a bit different, choose App Part and you’ll see your new Client Web Part listed.
You might be wondering what the difference between this and Web Parts are. Not much really. If you click Web Part and then choose Apps and you’ll see the same list.
If all goes well, your Client Web Part should now be visible on the page. You may be prompted for authentication again when it loads. You can adjust your browser security settings to avoid this.
At this point, you have a working Client Web Part. You can then make use of the Client Object Model or the new REST API to interact with SharePoint. I hope this helps you get started with building some apps. Try it out and see what you can do.
UPDATE: To use the JavaScript Client Object Model with an App Part, see this post.