At ORCS Web, we’re using System Center Configuration Manager (SCCM) with Microsoft Deployment Toolkit (MDT) and have it set to deploy new images to physical or virtual hardware.
Most everything works great, but the one thing I’ve wanted to get working is to add the Hyper-V Integration services to the Boot Image (WinPE in this case) so that 1) the regular Network Adapter (not the Legacy adapter) works and 2) there is mouse support right from the beginning. Once the boot image is created, the Hyper-V virtual machine can have the .ISO image mounted as bootable media.
Note that PXE boot with Hyper-V still requires the legacy network adapter (as far as I’ve been able to determine anyway). The better way to go is to use bootable media that can be mounted to the VM as a virtual CD/DVD drive. I’ll set out to cover how to do that here.
The following three links got me going in the right direction. However, it appears that the vmguest.iso file changed from when they wrote their blog posts until now, so I used different files then they did:
Here are the key steps:
- Go to an existing Hyper-V VM and insert the Integration Services Setup Disk. This is easiest with a server which you have already installed the Integration Services on so that you will have your mouse for the remaining steps.
- Don’t run the installation now. Instead, use Windows Explorer and navigate to the new drive and the Support folder. There are 2 subfolders: amd64 and x86. To create your 32-bit image, use the x86 folder. To create your 64-bit image, use the amd64 folder (even if it’s Intel 64-bit). I created two folders on my SCCM server. One for x86 and one for x64.
- Simply double click on the .cab file to view the contents. The file will be named Windows6.0-HyperVIntegrationServices-x64.cab or Windows6.0-HyperVIntegrationServices-x86.cab.
- Copy the contents of that cab file to your SCCM server. I do it over a UNC network path, but you can use whatever means of copying that you prefer. You don’t need all of the files in the cab, but it’s a small cab and easiest just to copy everything over.
Note: Now that you have the drivers, add them to your boot image. You can use whatever method that you use for your boot image, but I’ll include instructions for SCCM here.
- Fire up Configuration Manager Console (ConfigMgr Console).
- Expand Site Database (your instance) / Computer Management / Operation System Deployment.
- Right-click on Drivers and click Import. The Import New Driver Wizard appears.
- In the Locate Driver step, point to the folder where you copied the cab contents to. Run this twice, once for 32-bit and once for 64-bit.
- In the next step I imported all drivers even though I only use 4 on a later step. I figured that I may use them for something else in the future. So, leave everything checked.
- Assign a category that mentions the bitness of the drivers so that you can tell the difference later.
- In the Add Driver to Packages step, create a new package or assign to an existing package.
- Don’t do anything on the Add Driver to Boot Images step since we don’t want all of the drivers assigned to the boot images. Click Next.
- Click Next to finish the Driver import.
Now that the drivers are imported into SCCM, you need to add them to your boot image
- In the Drivers section of SCCM, find and select the following drivers for either x86 or x64:
- Microsoft Virtual Machine Bus Network Adapter (for network support)
- Microsoft Virtual Machine Bus Input Device Miniport (for mouse support)
- Virtual Machine Bus (I’m not sure if this is needed, but I added it anyway)
- Right-click and click Add or Remove Drivers to Boot Images.
- Check the boot image that you want to add to and click Update distribution points when finished.
- Finally, recreate your boot media.
Now you will be able to install an OS on a Hyper-V VM using the regular network adapter and mouse support.
As a side, I hoped that I could use x64 boot media and install both x64 and x86 operating systems. That would save me from choosing between the images as long as the hardware supports x64. Unfortunately it didn’t appear to work. I ran into driver issues later in the install process. I’m not saying that someone else can’t get it figured. It may be possible to embed the x86 drivers into the x64 boot image, but I didn’t take it that far. What I did prove is that configuring the x86 and x64 images identically wouldn’t allow the x64 boot image to deploy an x86 OS.
When it comes to deploying websites, many developers and companies have unique and creative ways to handle deployment. While some have fully workable solutions, I believe that there is a lot of room for growth to bring powerful and straight forward publishing tools to the masses and to support mature publishing methods for simple and complex sites alike.
Visual Studio 2010 introduces 1-Click Publishing which, along with Web Deploy, makes some nice strides in this area.
VS 2010 supports 4 methods of publishing content. They are: MSDeploy Publish, FTP, File System, FPSE. Let’s talk briefly about each:
MSDeploy Publish: this is the subject of this blog post and will be covered in more depth below. At it’s core, MSDeploy, aka Web Deployment Tool, is a command line tool used for deploying websites and settings. It can deploy or migrate website content, website settings, ACLs, COM, GAC and registry settings. As you can assume, the administrator on the target machine can specify which settings are allowed to be pushed. This is the foundation of many impressive deployment tools that we should expect to see coming out of Microsoft in the coming months and years. Visual Studio takes away the command line complexity of MSDeploy and provides the ability to deploy with a single click.
FTP: File Transfer Protocol has been around since the early days of the internet but has always had one major shortcoming—security. There are ways to make it security using SFTP (SSH FTP), FTPS (FTP over TLS/SSL) and some other methods, but the FTP protocol at its core is a plain text protocol, including the authentication (username/password). Recently we’ve seen a lot of progress for FTPS within Microsoft so that servers and tools support it, so be sure to use a secure method of FTP whenever possible.
File System: If you are on the same network or using a VPN connection to the destination web server then you can use the File System method of publishing. This uses straight xcopy to push the content directly to the destination location.
FPSE: FrontPage Server Extensions. FPSE has 2 aspects. One is the extensions part which were introduced with the Internet was fairly young, to support things like hit counters, email components and other bots. Some developers that develop with FrontPage use these. The other aspect of FPSE is publishing. FPSE offers a secure method of publishing content to a web server. However, FPSE has been plagued with security and difficult configuration issues over the years and, to my relief, I believe it’s on the way out. However, VS 2010 still offers support for pushing with FPSE, so if your destination servers supports FPSE, you do have this publishing technology available to you.
The remainder of this blog post is a simple walkthrough on publishing using MSDeploy, which can be done over HTTPS, providing much better security than plain text FTP. The host or production servers need to support MSDeploy.
Playground
ORCS Web has worked with Microsoft to provide a testing account so that you can try out MSDeploy completely free of charge. This promotion is available for a few months starting in June 2009. Vishal Joshi has formally announced this plan also. If you want to try out the publish feature covered here, but don’t want to setup and configure a production server, sign up for one of these accounts.
Publish Web Tool (using MSDeploy Publish)
You can access the Publish Web Tool either by the top menu: Build –> Publish {project name} or from the Publish menu:
Open the Publish Web tool to get started.
The tool should look like this, but the fields will change with the different Publish Methods. We’ll just cover MSDeploy Publish here.
If you don’t have the information from your host or server admin team, make sure to obtain that now. I’ll cover the fields and what they mean here:
Profile Name: (at the top) This is the friendly name that you provide to reference your deployment profile. Visual Studio 2010 supports up to 50 profiles.
Publish Method: These are the 4 methods mentioned above: MSDeploy Publish, FTP, File System and FPSE.
Service URL: This is the MSDeploy URL that your administrator or host provides. It will be something like https://ServerNameOrIP:8172/MsDeploy.axd
Site/Application: This is the IIS site name, but it’s more than that. Within this field you can specify a sub folder(s) where your project will be deployed. Your host or administrator will likely provide the root path that you have access to, for example SiteName or SiteName/vdir. But you can optionally be more specific in the path, like so: SiteName/ProjectName. The root Site/Application name must be exactly the name of the destination IIS Site (plus optionally the application).
Mark as IIS application on destination: If you set a sub folder for the “Site/Application” field and check this checkbox, it will mark the folder as an application root when publishing. Your host/administrator must support this on the destination server.
Do not delete extra files on destination: If this is unchecked it will first delete everything from the destination folder before publishing the new content. You will likely only want this unchecked for the initial deployment and then have it checked every time after that, until you want to start fresh.
Allow Untrusted Certificate: The certificate that your host/administrator uses may be a self-signed certificate or it may be for a different name than the URL. Only check this if your host or administrator instructs.
User Name and Password: This is the username and password used to connect to IIS, likely provided by your host/administrator.
Save password: This goes without saying. It’s up to you whether you have Visual Studio save your password or not.
Once you’ve filled out the fields, you can Publish immediately or Save so that you can publish later.
If all is setup correctly, you can publish by clicking the Publish button, or from the 1-Click Publish button. The 1-Click Publish feature is literally that: after setup, when you make a change that you want to publish to the web, just click that one icon and it will take care of the deployment.
In my opinion, the most impressive feature of MSDeploy is that it only publishes the changes between the source and destination location. If you have a 2GB site but only changed 2 files, when you click Publish, it will deploy only the changes, very rapidly. Additionally, from a network and server utilization perspective, MSDeploy is much faster and efficient than IIS FTP.
Shortcoming – error reporting
The biggest shortcoming that I find is regarding the error reporting when something goes wrong. VS 2010 doesn’t expose to you very much information about the errors. Most error information is available to the host administrator on the destination server. If you receive an error that isn’t clear, double check each of the fields. The most common failure is related simply to incorrect information.
There’s more, but not here and now.
Visual Studio’s Publish feature has a lot more. The two other most significant features are the Database Publishing and MSDeploy’s Transform feature so that your web.config settings can be changed as they are published.
I’m not going to cover them here and no though, but I’ll provide some useful links below which cover all of these features in more detail.
Links.
The best walkthroughs and information on MSDeploy and Visual Studio’s 1-Click Publish feature likely comes from Vishal Joshi. He’s a program Manager with Microsoft for these technologies and is an authoritative source of information. Start with this blog post: Web 1-Click Publish with VS 2010
Keep an eye open for more publishing tools and progress in the future. I believe we’re just at the beginning of great things to come.
With Microsoft Visual Studio 2010 Beta 1 released and available as a free download, we at ORCS Web have joined with Microsoft to provide a free testing account so that you can see for yourself how the Publish feature works for remote publishing.
As of today, you can setup a new account free of charge here. Note that this account is setup with ASP.NET 4.0 by default, which does not have a go-live license, so this account is for testing purposes only and cannot be used to host a production website.
Visual Studio 2010 now supports Web Deployment (MSDeploy) which is an impressive new technology from Microsoft, allowing rapid deployment of websites. It’s fully secure since it runs over SSL, and yet it’s lightening fast. It only copies the changed files and only the necessarily files, making deployment a breeze.
VS 2010 totes a single-click publish option now. Once you set it up, which is easy, you can deploy changes with one click.
I’ll follow up with a walkthrough with more information later this week, but I wanted to mention our hosting offer today. We didn’t launch on the same day as Bing on purpose, but we can pretend that it’s all part of planned launch to keep up with the hype. :)
Here’s the link to setup an account: http://www.orcsweb.com/hosting/vs2010beta.aspx