Using Hyper-V to Build a Private Cloud (Part 10)

If you would like to read the other parts in this article series please go to:

Introduction

If you have been following along with this series over the last several months then I sincerely hope that all of your hard work was rewarded in Part 9 when you used the Self Service Portal to generate a virtual machine. If not though, then it’s not the end of the world. I want to wrap up the series with this article discussing some troubleshooting techniques that you can use if things didn’t quite go according to plan. I also want to talk for a moment at the end of this article about some security considerations.

What Went Wrong

Unless everything is configured properly, a user who attempts to create a new virtual machine may be left scratching their head wondering what happened. The creation process can be monitored through the Self Service Portal’s Jobs tab. When a failure does occur, the jobs tab will report the failure, but the error message may be less than helpful. For example, if you look at Figure A, you can see that the error message basically just says that something went wrong.


Figure A: The Jobs tab provides vague error messages.

The trick to deciphering these types of errors is to understand that the error messages displayed on the Jobs tab are often hierarchical, even though they are not displayed that way. To show you what I mean, take a look at Figure B. In this figure, I have expanded the screen capture so that the full contents of the Jobs tab are displayed.


Figure B: Errors are typically related to one another.

At first glance, these would appear to be two unrelated error messages. However, take a look at the Start Time and End Time columns for the two errors. They are exactly the same. The error message at the bottom of the figure is the error that actually caused the problem. The error message at the top is a general failure error message that occurs as a result of the first message. I’m not really sure why Microsoft chose to present errors in this way. As a general rule though, just ignore the more general error. If you correct the error with the more granular description then the primary error will go away too.

So how do we get rid of this error. Well, if you look at the Error Details column, you will see that the description indicates that the Virtual Machine Manager was unable to find a value for the required Sysprep parameter ProductKey. In essence either the entire Sysprep.inf file is missing (which it is in my case), the Sysprep.inf file is not being processed, or the ProductKey parameter is missing or invalid.

In my case, this error occurred because of the way that the Windows Deployment Services works. When you attempt to deploy an image, the Windows Deployment Services looks for a Sysprep.inf file that goes along with the image. The Sysprep file provides various parameters to Windows Setup. For example, the Sysprep.inf file provides things like the product key, the time zone, and the administrator’s password.

Given the nature of what the sysprep.inf file does, the Windows Deployment Services require you to create a separate sysprep.inf file for each deployment image. I intentionally omitted the sysprep.inf file from my deployment image so that I could demonstrate the troubleshooting process.

There are two main things that you will need to keep in mind with regard to the sysprep.inf file. First, the exact location in which the sysprep.inf file should be stored varies depending upon the path that you used for the Windows Deployment Services. Second, the sysprep.inf file must exist in plain text format.

Another common issue that you may encounter is a message telling you that the server actively refused the connection (while working in the Self Service Portal). This tends to happen if some of the system services are not running. Depending on which services are running, it is sometimes possible to browse, but not modify settings within the Self Service Portal. The problem has the symptoms of a security problem even though a system service is actually at fault.

To correct the problem, select the Services command from the server’s Administrative Tools menu. When the Service Control Manager opens, check to make sure that every service that has a Startup type of Automatic is actually running. If you find a service that is supposed to start automatically, but is not running then you can right click on that service and select the Start command from the shortcut menu.

Of course you may experience problems that I have not described here. If such problems do occur then one option is to search the Internet for the particular error message that you are receiving. Often times you will find a Microsoft support forum with the answer to your question.

Another thing to do is to check the server’s event logs. The Application and the System log may contain clues to the nature of your problem, but don’t forget to check the Virtual Machine Manager SSP and the VM Manager logs as well. These logs are located under Application and Services Logs\Microsoft.

A Word About Security

Before I wrap things up, I want to talk for a moment about user roles. The Self Service Portal contains a User Roles tab that displays four built-in user roles. You can also create custom user roles, but I would recommend sticking with the default roles unless you have a compelling reason to create a custom role.

With that said, each of the built-in roles is designed for use in a different situation. You can select a role to see what types of actions are allowed by users who hold that particular role. By default the DCITAdmin, BUITAdmin, and AdvancedOperator roles contain exactly the same privileges. You can of course modify these privileges to meet your needs.

My personal recommendation would be to leave the DCITAdmin and the BUITAdmin roles alone. These roles are specifically designed for administrative purposes and shouldn’t normally be modified. It is fine to modify the AdvancedOperator and the BusinessUnitUser roles. Each role should contain the minimum set of privileges that the user requires to do their job, and nothing more.

It is also worth noting that you can verify which users have been assigned to each role by selecting the role and then clicking the View / Edit Members link. You can also use this link to add users to the role.

Conclusion

Although it is initially a lot of work to build a Hyper-V based private cloud, the cloud that you have created should save a lot of administrative effort later on. Approved users can generate virtual machines on the fly by using the templates that you have created. Furthermore, the templates are easy to modify whenever your needs change. By using the Deployment Workbench, you can easily adjust task sequences to include new applications, drivers, etc. in your deployment images.

If you would like to read the other parts in this article series please go to:

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top