vRA/SCCM integration challenges

[stacycarter]

We're trying to test the native vRA 6.2.2/SCCM 2012 R2 integration right now and we're pretty close to having it working.  We're able to get the OS and SCCM agent to successfully install via the SCCM task sequence.  However, at the end the vRealize Agent script/installation gets stuck (we used the "Create a Software Package for SCCM Provisioning" VMware doc steps to set it up).  Has anyone seen this happen before, or any idea what could cause this? 

In addition, we want to get to the point where VRA successfully gets an updated status from SCCM after the OS installation completes (the status of the VM in vRA never updates past "InstallingOS", even if this part completes successfully).

pizzle85

[pizzle85]

Adding this as its been relevant to this same question several times in the past.

Is your management service behind a load balancer where the deployed machines IP address can not directly access the individual IaaS management services? If that's the case then you will run into an issue where the vCAC Agent will try to communicate with the management server that deployed the machine directly, which will result in a hang. I had to modify the GuestAgent.vbs script in the guest agent package as follows:

'End If  
  
' CUSTOM  
isItHttps = 1  
h = "LoadBalancer FQDN:443"  
  
' Have to fix the bat file that actually runs agent executable  

This basically overwrites the scripting that decides which management node to communicate with.

[pizzle85]

Id look at the  Vrm.ProxyAgent.Uri and VrmProxyAgentUri CM device variables. They should be set to the FQDN of your vRA management node. If this should be a FQDN for a LB see the above reply. You need to verify the IP address assigned to the machine and verify it can communicate with URL defined in the the VrmProxyAgentUri variable. You should be able to log into the server via RDP or through a console session at the point that it hangs. Log in and try to hit the URL in a web browser from that machine. If you can resolve it then there's something else going on.

[stacycarter]

Do we need to set a Microsoft.SMS.TSEnvironment variable in the task sequence?  I see that being referenced in the guestagent script, how does it get that variable?

[pizzle85]

No. That is the method to grab the OSD and Device Variables from the SMS OSD TS (task sequence). That's basically just grabbing all the environment variables and storing them in the "env" object. Then on the next like the extract the management endpoint to connect to by getting the value of the env("Vrm.ProxyAgent.Uri") variable.

You need to "Enable command support" on the boot media under the "Customization" tab. With that enabled you can open a console session to the VM being deployed through vCenter, hit F8 to get a command prompt. From there you should be able to check that you have an IP address and you can also check the C:\Windows\CCM\logs\SMSTS.log file to see what the task sequence is doing.

My guess is that you either dont have a correctly configured NIC and you cant communicate with the manager. Or that the manger IP address is not permitting traffic from the IP address you server is on. Another issue could be that smsts is trying to communicate with the wrong endpoint.

In our environment I pass the boot up the windows boxes on a DHCP network during the install and provide the permanent IP information as variables. At the end of the TS i run a powershell script that configures the NIC on the permanent IP and during the vRA "provisioned" stage we move the VMs NIC to the permanent port group. All the device variables except the two Vrm variables are custom.

[stacycarter]

Thanks for the additional info pizzle85  Yes, we pretty much went through the steps you mentioned.  The test VM has the correct name of the vCAC IaaS server in SCCM properties. The VM also has network connectivity and the correct port group; we are currently only using DHCP for testing, and the VM successfully got it's IP/DNS settings, joined the domain during the task sequence and can talk to SCCM (and we can RDP to the VM).  We've got F8 support enabled, but that hasn't helped us much with troubleshooting the vRA guest agent deployment/install (via SCCM).

Are you just running the vbs script for your GuestAgent step?  Like in the image I attached...

[pizzle85]

Yup.

There's only a few issues i can think of at this point:

The install is failing. You would be able to see this in the SMSTS log file or in the gugent installation log files.

The deployed machine can't communicate to the mgt server over 80 or 443. You said you had connectivity to the CM server but didn't specify if you could get to the management server.

I did run into an issue where i updated vRA but didn't update the guest agent package and it required the newest version to work correctly. Make sure you're using the version that matches your vRA installation.

I also ran into another issue where the ROOT and INTERMEDIATE certificates for the SSL certificate issued to the management service were not in the windows key store by default. Initially i was pushing them to the box as a TS step but ended up re-configuring our F5 load balancer to present the entire chain. Again this would be visible in the SMSTS log or the gugent installation logs. Or by attempting to browse to the management service on the deployed machine.