I was chilling at home building a new computer with my RTM version of Vista. Joined it to my home domain. I tried accessing Live.com. first thinking live.com was down. Later I started wondering about my Comcast connection. Then I start doubting my router. So I thought for I while trying to figure out what was wrong. Only then did I decide to pay attention to the little orange shield in the task bar. I remember glazing over it earlier, but I disregarded it as an indicator of the firewall for some reason. Once I investigated the orange shield. I found myself in quarantine.

I forgot about NAP was enabled on my home network… Click on the screen shot below.

.

.

Gotta love it …

1. go into the VMM database to the table tbl_WLC_VObject, and change the ObjectState field of the problem VM, which probably has the value 104, to value 1

** At this point, i went direct to the table and edit the value manually. Of course I did this because this I a Lab environment.

update dbo.tbl_WLC_VObject
set ObjectState = 1
where Name = '<VM name>'

2. in VMM admin console, you're VM will now have the status missing, now just delete the VM and it's gone.

Answer found here on :  --> http://social.technet.microsoft.com/Forums/en-US/virtualmachinemanager/thread/872034ba-3545-4431-b9f6-07ee8c65188b 

Description: The Most Secure Way to Provision System Center Update Publisher (SCUP) Certificates for Client Machines and the WSUS/SCUP Server.

Supporting Article: http://social.technet.microsoft.com/forums/en-US/configmgrsum/thread/f53e8ee3-dfc9-4d4b-92e6-447546150853

Notice the certificate that SCUP uses or will accept when configuring the certificate in SCUP in the Settings location within the console, SCUP will only accept .PFX Personal Information Exchange certificates. So this means that .CER certificates cannot be used with SCUP. If you use a certificate you configured for IIS and WSUS as the above article mentions, you have to export the certificate out to a .PFX certificate before SCUP will accept and can use it.

Since this wasn't mentioned in documentation I, or I can't find it, members on my Team, and I'm sure others, was exporting the .CER type certificate. Which does not work or is accepted my the SCUP product.  

So what should be known and what I've discovered is the following:

Must use a .PFX Personal Information Exchange certificate when importing a Cert into SCUP under the Setting Option. Since this is a .PFX cert which holds the Public and Private Key, you do not want to deploy this type of certificate on client machines. This would be like giving out your login id and password to everyone that gets the certificate.

What you want to do is export ONLY the Public Key portion of the PFX certificate, which then will be a .CER certificate built from the .PFX certificate and only has the Public Key. Then you can use Group Policy to deliver the certificate to clients.

So I would see the steps as follows:

On the WSUS/SCUP Server

Step 1. Click Start -> Run -> MMC

Step 2. File -> Add/ Remove Snap-In -> Add -> Certificates

Step 3. Choose Computer account -> Local Computer -> Add -> Close -> OK

Step 4. Expand Certificates (Local Computer) -> Expand WSUS -> Click Certificates

Step 5. Find the Certificate you created for use WSUS/SCUP, or Find the Self Sinning certificate automatically created by SCUP, Right Click it -> All Tasks -> Export. Must be a .PFX certificate.

Note and Remember: A .PFX Personal Information Exchange certificate holds the Public and Private Key. So 1. you don't want to deploy this type of certificate on client desktop computers. and 2. You do not need this type of certificate in the Trusted Publishers and Trusted Root Certification Authorities store. The .CER type certificate will work just find and does not have the Public Key associated with it.

Step 6. Click Next -> No, do not export the private key -> Next -> Select Base-64 encoded X.509 (.CER) -> Provide a location to export the certificate to -> Next -> Finish, to export the certificate.

Note: Base-64 encoded X.509 (.CER) is the highest encryption method that you can export to a (.CER) certificate.

For Provisioning the Certificate on the WSUS/SCUP server.

Step 7. Expand Certificates (Local Computer) -> Expand Trusted Publishers -> Click Certificates -> All Tasks -> Import -> Next -> Browse to the cert.CER file you just exported -> Next -> Ensure Place all certificates in the following store is selected. -> Next -> Finish, to complete importing the certificate.

Step 8. Expand Certificates (Local Computer) -> Expand Trusted Root Certificate Authorities -> Click Certificates -> All Tasks -> Import -> Next -> Browse to the cert.CER file you just exported -> Next -> Ensure Place all certificates in the following store is selected. -> Next -> Finish, to complete importing the certificate.

Now you only have Public Key in the "Trusted Root Certificate Authorities" and "Trusted Publishers" these stores.

Note: When you Import your own .PFX cert or using the Self-Signing Cert SCUP creates in the WSUS\Certificate Store, You now only have the Public Key for this Cert in one location on the WSUS/SCUP server. This is the most secure way of configuring the SCUP certificate.

Step 9. Perform Steps 7 and 8 to import the certificate manually on client machines. Or you can use Group Policy to deploy the cert.cer to client machines.

I posting a Workaround for a issue I found and notice that other people running into. So far I not seen or found a root cause or a fix. But this work around is the best I have discovered and better than rebooting the Hyper V host to resolve the issue.

Link to the Article on Tech Net:
URL: http://social.technet.microsoft.com/forums/en-US/virtualmachinemanager/thread/ac48fd59-3de9-4191-8466-25bedee3f5b1

Workaround:
Though I have not found the root cause, but I did find something of a workaround that quickly brings the Hyper V host back to a functional state.

When I see the error of :

Error (2912)
An internal error has occurred trying to contact an agent on the servername.domain.com server.
(No more threads can be created in the system (0x800700A4))
Recommended Action
Ensure the agent is installed and running. Ensure the WS-Management service is installed and running, then restart the agent.

I go to Services and Restart the "Windows Management Instrumentation" Service. Restarting this services also restarts the following services: (if they are on your server)

• Hyper V Virtual Machine Management
• Virtual Machine Manager Agent
• Hyper-V Image Management Service
• Hyper-V Networking Management Service
• IP Helper
• EMC PowerPath Service 5.1.2
• SMS Agent Host

Due to the type of services that are also restarted when doing this, and if the Hyper V host is in production. I would suggest doing this with caution and sending a user awareness notification for the temporary outage. Though the outage is small depending on how long it takes for certain services to start.

Because the Hyper-V Image Management Service is restarted. Users will not be able remote control a virtual machine or may be kicked off the VM remote control session. And if you are doing this while TS into the Hyper V host server, you may lose TS connectivity momentarily.

Problem Statement:

I am getting an error, that is causing the hyperV to be unstable. I have 3 hyperV servers in my test env, runnning about 45 clients. All 3 are reporting this error at some point through the day. This often means that I need to restart the service hyperV Virtual Machine manager, and obviously during that time the SCVMM server (which is a VM client within these 3) looses contact until the service is restarted.

Article and Solution: http://social.technet.microsoft.com/Forums/en-US/virtualmachingmgrhyperv/thread/02adb29a-c3b8-41c5-80fc-99e6a67d39fc 

Answer:

The problem is a known bug and is fixed in Windows 2008 SP2.
The problem is due to having a virtual machine configured with a SCSI adapter that does not have a drive attached to it. I had virtual machines with this configuration. since removing the un used SCSI adapter, my Hyper V service does not stop and restart.
So go thru each VM and remove any SCSI adapters that does not have a drive associated with it.
Hope this helps you guys.
Thanks

Recently I found some of my virtual machines stuck in a starting state. When I right click on the VMs that's stuck in the starting state, I only receive the following options: Connect...; Settings...; Rename... and Help. (screen shot below).

I was unable to force Shut down the VM or Stop the VM using the context menus. Even after stopping and restarting all three of the Hyper-V services,

1. Hyper-V Image Management Service
2. Hyper-V Networking Management Service
3. Hyper-V Virtual Machine Management

the VMs are still in the stuck state and still will not stop or continue to start.

I rebooted the Hyper-V server host, and the VMs are stay in the stuck state. I took a look at the Tasks manager to see if I saw either of the services using an abnormal amount of memory or anything out of the ordinary. Nothing really stood out as being strange. But I did notice a series of services running with the name of "vmwp.exe" with the description of Virtual Machine Worker Process. About as many as I had VMs configured on the Hyper-V host. I noticed that most of the processes was consuming around 4,000k to 5,000k of Memory (Private Working Set) or more. But 6 of these processes was only using just about 500k or 600k of memory. This was the exact amount of VMs I had stuck in the starting state.

So I decided to kill one of the processes that was around 500k, and as soon as I did, one of the VMs in the starting state kicked off like it was starting for the first time showing the starting percentage indicator then the VM started and status changed to Running. I didn't get a snap shot of the processes running with low memory for a VM that was stuck in the starting state, but I have posted a snap shot of what I'm referring to below.

Weird! This is how I resolved this issue I had. So hopefully this will help someone else, if anyone else if having this issue, and if so hopefully we'll find the right solution.

 
Click the Image above to enlarge view.

It's up on us again, MMS 2009 and I'm going to try and be there to talk about how you can enable and configure your environment to protect your network with Network Access Protection against virtual machines on virtual private networks that have connectivity to the physical network. The presentation I plan to give will show how to enabled a protected network from virtual environments.

I will show you how to automate a complete solution, enabling you to deploy virtual machines with WDS using SCVMM 2008, Hyper V and SCCM 2007 on a Windows Server 2008 Active Directory Network with Network Access Protection (NAP) enabled. I will show a demo on an automated provisioning process that will allow deployed virtual machines to receive the System Center Configuration Manager client using Active Directory Group Policy and WMI filtering as the discovery method. This allows targeting of virtual machines with specific group policies to allow Windows Software Updates Services (WSUS) & ConfigMgr Software Update Point (SUP) client installation configurations to automate the client installation.  

As we all know virtual machines can be configured with a private internal network adapter which does not allow the virtual machine to connect to the physical network, and wouldn't matter if the virtual machines are unhealthy, or with a externally facing network adapter that is connected to the physical network and if joined to the corporate domain those virtual machines will have access to the physical network and resources the Hyper V host is sitting on. In the event when a administrator deploys his/her virtual machine that is connected to the physical network, this solution can automate discovery of virtual machines and protect your network from virtual machines that may be un-patched or un healthy.

I will show the virtual machines go in quarantine soon after a WDS deployment and how the virtual machine will automatically receive the System Center Configuration Manager client, following the client installation, all required software updates are installed as well which will be followed by a post configuration custom software update developed with System Center Custom Update Publishing Tool. 

This solution addresses the possibility of un-patched virtual machines being deployed to a corporate enterprise network. This solution integrates software updates management, automated client deployment for the Configuration Manager client, WDS for operating system deployments, Active Directory Group Policy as the targeting method, custom software updates with SCUP, and Network Access Protection for systems health validation. This solution also has the potential of reaching 99% client coverage within an enterprise, provided standards and standard configurations are put in place and adhered to.

Getting to 99% coverage on client deployments was not possible until the introduction of System Center Configuration Manager 2007 and its newest feature, WSUS/Software Update Point Client Installation, in my opinion. I wrote a article for this solution, You can find it Here!.

Network Access Protection (NAP) is a new set of operating system components in Windows Server 2008, Windows Vista, and Windows XP Service Pack 3 that provides a platform for system health validated access to private networks. This solution will show how to extend the platform to also validate virtual machines deployed on virtual networks that inter-connect with the physical network. 

The NAP platform provides an integrated way of validating the health state of a network client that is attempting to connect to or communicate on a network and limiting the access of the network client until the health policy requirements have been met. These policy requirements can also be extended to include virtual private networks for network environments that allow administrators to deploy and manage their own virtual machines that will have access to the corporate physical network.

I see the requirements as to validate access to a network based on virtual machines system health, a network infrastructure needs to provide the following areas of functionality:

· Health state validation

· Network access limitation 

· Automatic remediation 

· Ongoing compliance 

· Virtual machine discovery - how is this done? I will have more on this at MMS 2009 in Las Vegas and on my blog soon after.

I'll let you know if and when its official that I'll be there at MMS in 2009...

System Health Validator Placement

I'm writing this post in response to some Configuration Manager 2007 Network Access Protection questions I received during the MMS 2008 conference.

"Where to place the System Health Validator Point Role (SHV) be in the ConfigMgr 2007 hierarchy?" The quick simple answer is at the Central Site in the hierarchy, or at the Site where your ConfigMgr administrators will perform daily administrative duties on. Some companies may have a Site or Reporting Site setting on top on the Central Site of the hierarchy, as shown below.

For the above design, you will want to install a System Health Validator Point Role (SHV) from the Central Site just the same as if you do not have a Reporting Site setting over the Central Site of the hierarchy.
Installing a SHV and all subsequent additional SHV’s from the Central Site is recommended and provides centralized management of all SHV settings and configurations for System Health Validator. Below is a list of reasons to install all SHV’s from one Site or the Central Site server.
All SHV settings and configurations are set by modifying the Systems Health Validator Point Component from the Components Configurations Node under Site Settings from within the ConfigMgr Console. Settings and configurations set here applies to all SHV’s that are installed from the same site.
Note: The SHV and the Site server have no bi-directional communication with the Site server it is installed from. So the SHV can actually be installed on any Site within the hierarchy, but will have no benefit or additional functionality by doing so. Please don’t make the mistake in thinking that you will need a SHV per Site. One SHV can facilitate one hierarchy.
You can stage up to 4 NPS/SHV servers that clients can communicate with. Clients will use the first NPS/SHV server in the clients Trusted Server Group. Below shows the configuration settings of the SHV/NPS URL’s that clients will communicate with when send NAP SOH requests.
To see the below list on a client, run the below command line in an elevated command prompt on a Vista system:
C:\> netsh nap client show group

Names have been changed to protect the innocent…

Trusted server group configuration:
----------------------------------------------------
Group            = MSIT
Require Https    = Enabled
URL              = https://NPSServer1.widget.contoso.com/domainHRA/hcsrvext.dll
Processing order = 1
Group            = MSIT
Require Https    = Enabled
URL              = https://NPSServer2.widget.contoso.com/domainHRA/hcsrvext.dll
Processing order = 2
Group            = MSIT
Require Https    = Enabled
URL              = https://NPSServer3.widget.contoso.com/domainHRA/hcsrvext.dll
Processing order = 3
Group            = MSIT
Require Https    = Enabled
URL              = https://NPSServer4.widget.contoso.com/domainHRA/hcsrvext.dll
Processing order = 4

The System Health Validator can be installed on to a Windows Server 2008 running the Network Policy Server service (NPS) that is joined to any domain or forest other than the domain the Site server is joined to. In the case where the NPS server is joined to separate domain forest than the Site server is joined to, the NPS servers, by default the NPS servers will query for client health state reference in the forest the server is joined to.
This means if you have a Site server joined to forest A, and one NPS server joined to forest A, and another NPS server joined to forest B. The NPS/SHV servers will query and validate client’s health state from the domain the NPS server is joined to. The picture below shows this representation.

This can cause your Windows NAP infrastructure to validate only a subset of your clients and will only validate client’s compliance that is in the same forest as the NPS/SHV server. Previously I mentioned modifying SHV properties for the Systems Health Validator Point Component from the Components Configurations Node under Site Settings. On the Health State Reference Tab, you have the option to specify a Domain suffix where you want the SHV/NPS servers to query for client health state reference. When this option is set to a specific Active Directory forest FQDN example: corp.contoso.com, this tells all SHV’s installed from the Site to publish to the same domain forest root.
This provides centralized management of all SHV’s and its settings. And you will want all your SHV’s configured with the same setting and configurations. As clients hit the first SHV/NPS server when sending SOH requests (SOH = Statement of health), they will be validated by the first SHV in the list, and will fail over to the next SHV/NPS in the list with the first NPS server in the list hits maximum connections, and you will want the next SHV/NPS to validate clients with the same validation settings and configurations.
If you setup a SHV at each Site in a hierarchy, you will be actually duplicate administrative work that is not required. You will have to go to each Site and configure the properties for the Systems Health Validator Point Component from the Components Configurations Node under Site Settings.

If you have access to Microsoft Connect, get R2 for System Center Configuration Manager 2007 SP1. Its out and you and get a hand on preview of some of the feature R2 will bring. Download not from Microsoft Connect.

Some how I stumbled on a web page I never seen been for, which is cool. The official home page for System Center Configuration Manager. As you'll notice on the front page that it does not say 2007. most likely because the site is not dedicated to that specific version. It looks to me that its focused on system management in general. I believe as the growing demand increases around desktop management, there will always be a need for a product to manage desktops remotely and in a unified way. Check out the original Home Page for System Center Configuration Manager. 

I see links all over about this new piece of documentation released.  But, there’s a really good story here that I think a lot of us are missing.  This is a great story about how Microsoft listens and reacts to community feedback – at least the documentation team for System Center Configuration Manager does.

As a community, we’ve worked with this team for a long, long while.  The lines of communication have always been two-way and the partnership has always been fruitful and valuable.

For example…here’s the actual announcement from Carol Bailey about the new docs to Ed and Mike at 1E…posted by Ed to the SMS list today…

Read more here: --> http://myitforum.com/cs2/blogs/rtrent/archive/2008/07/03/how-to-configure-isa-ssl-bridging-for-system-center-configuration-manager-internet-based-client-management-the-real-story.aspx

Friday, May 23, 2008   |   5 Comments   |  

For a prospect customer there's nothing better than a real-world implementation to realize the potential or a certain technology. And this is very true in an almost unexplored technology like virtualization.

Microsoft, which eats its own dog food since the Virtual Server 2005 era, just announced the complete migration of both MSDN and TechNet, two of the most popular web sites in the world, on virtual machines.

Microsoft kept the back-end database on physical boxes, but moved 100% of its IIS7 frond-ends on Hyper-V RC0 VMs with 4 virtual CPUs and 10GB RAM.
The virtualization hosts (no mention of the brand obviously) are powered by 2 Intel quad-core CPUs and 32GB RAM (2GB are reserved for the Windows Server 2008 parent partition).

Follow the link below to learn more.
http://www.virtualization.info/2008/05/microsoft-migrates-msdn-and-technet-on.html 

System Health Validator Placement

I'm writing this post in response to some Configuration Manager 2007 Network Access Protection questions I received during the MMS 2008 conference.

"Where to place the System Health Validator Point Role (SHV) be in the ConfigMgr 2007 hierarchy?" The quick simple answer is at the Central Site in the hierarchy, or at the Site where your ConfigMgr administrators will perform daily administrative duties on. Some companies may have a Site or Reporting Site setting on top on the Central Site of the hierarchy, as shown below.

For the above design, you will want to install a System Health Validator Point Role (SHV) from the Central Site just the same as if you do not have a Reporting Site setting over the Central Site of the hierarchy.
Installing a SHV and all subsequent additional SHV’s from the Central Site is recommended and provides centralized management of all SHV settings and configurations for System Health Validator. Below is a list of reasons to install all SHV’s from one Site or the Central Site server.
All SHV settings and configurations are set by modifying the Systems Health Validator Point Component from the Components Configurations Node under Site Settings from within the ConfigMgr Console. Settings and configurations set here applies to all SHV’s that are installed from the same site.
Note: The SHV and the Site server have no bi-directional communication with the Site server it is installed from. So the SHV can actually be installed on any Site within the hierarchy, but will have no benefit or additional functionality by doing so. Please don’t make the mistake in thinking that you will need a SHV per Site. One SHV can facilitate one hierarchy.
You can stage up to 4 NPS/SHV servers that clients can communicate with. Clients will use the first NPS/SHV server in the clients Trusted Server Group. Below shows the configuration settings of the SHV/NPS URL’s that clients will communicate with when send NAP SOH requests.
To see the below list on a client, run the below command line in an elevated command prompt on a Vista system:
C:\> netsh nap client show group

Names have been changed to protect the innocent…

Trusted server group configuration:
----------------------------------------------------
Group            = MSIT
Require Https    = Enabled
URL              = https://NPSServer1.widget.contoso.com/domainHRA/hcsrvext.dll
Processing order = 1
Group            = MSIT
Require Https    = Enabled
URL              = https://NPSServer2.widget.contoso.com/domainHRA/hcsrvext.dll
Processing order = 2
Group            = MSIT
Require Https    = Enabled
URL              = https://NPSServer3.widget.contoso.com/domainHRA/hcsrvext.dll
Processing order = 3
Group            = MSIT
Require Https    = Enabled
URL              = https://NPSServer4.widget.contoso.com/domainHRA/hcsrvext.dll
Processing order = 4

The System Health Validator can be installed on to a Windows Server 2008 running the Network Policy Server service (NPS) that is joined to any domain or forest other than the domain the Site server is joined to. In the case where the NPS server is joined to separate domain forest than the Site server is joined to, the NPS servers, by default the NPS servers will query for client health state reference in the forest the server is joined to.
This means if you have a Site server joined to forest A, and one NPS server joined to forest A, and another NPS server joined to forest B. The NPS/SHV servers will query and validate client’s health state from the domain the NPS server is joined to. The picture below shows this representation.

This can cause your Windows NAP infrastructure to validate only a subset of your clients and will only validate client’s compliance that is in the same forest as the NPS/SHV server. Previously I mentioned modifying SHV properties for the Systems Health Validator Point Component from the Components Configurations Node under Site Settings. On the Health State Reference Tab, you have the option to specify a Domain suffix where you want the SHV/NPS servers to query for client health state reference. When this option is set to a specific Active Directory forest FQDN example: corp.contoso.com, this tells all SHV’s installed from the Site to publish to the same domain forest root.
This provides centralized management of all SHV’s and its settings. And you will want all your SHV’s configured with the same setting and configurations. As clients hit the first SHV/NPS server when sending SOH requests (SOH = Statement of health), they will be validated by the first SHV in the list, and will fail over to the next SHV/NPS in the list with the first NPS server in the list hits maximum connections, and you will want the next SHV/NPS to validate clients with the same validation settings and configurations.
If you setup a SHV at each Site in a hierarchy, you will be actually duplicate administrative work that is not required. You will have to go to each Site and configure the properties for the Systems Health Validator Point Component from the Components Configurations Node under Site Settings.
If you have any questions on SHV setup of placement, please ask.

There are a lot of questions in newsgroups, forums etc. about how to use Restricted Groups in the right way so I wanted to post a how-to for people to read.

Finding Restricted Groups is easy but it only works in a domain with Active Directory so trying to find it within your local GPO on your computer isn’t possible.

At first you right click on Restricted Groups and select “Add Group”.
What you get is the default window to choose a group, either from your domain or maybe from your local computer depending on what configuration you want.

Now you have two different choices of what you want to do with the group you selected. Either you use “Members of this group” or “This group is a member of”. The differences of these choices are big so I explain in two steps.

Members of this group

This is the choice you make when you want to add users to a group. What you select here is what you will see on your computers affected by this policy. So if you for example want to add a user to the local admin group on the computers then don’t forget to add administrator also or the administrator account will be removed from the local administrators group on the computers.

As an example can be this picture where you have both the local administrator account and also the built-in Authenticated Users group.

This group is a member of

This choice you can use if you want to add your selected group into another group. So what you can tell is that this is the opposite of what you defined in choice 1 described above. This is also not something that will override any other configuration you have done. So if you in first choice selected “Authenticated Users” and with this option select that it will be added to the “Administrators group” any other user you might have added to the group (manually perhaps) won’t be overwritten by this choice.

So this example which you can see in this picture will add the “Power Users group” into the “Administrators group”.

To summarize this it’s fairly easy to use Restricted Groups and it’s also the easiest way to add/remove users in groups and you can control it in a much better way than you ever can doing this manually. If you are doing this manually today it’s time to stop and using the right way instead.

Though the building alone covers a whopping 11 acres, you can't even see Microsoft (NSDQ: MSFT)'s new $550 million data center in the hills west of San Antonio until you're practically on top of it. But by that point, you can hardly see anything else.

Read more here.