I have been troubleshooting this problem with our SCCM guy
It turns out the vRA workflow tries to add the machine straight to the collection named in the blueprint, which finds fine BUT.... the device needs a be a member of the All Systems collection before it can add to a specifically named collection. This causes the delays and attempts to communicate every 10 seconds or so. This is a requirement from SCCM 2012 onwards. SCCM 2007 is does not have the All systems requirement.
I am trying to work around this by naming 2 collections in the blueprint (but i am expecting it to only except the first one and ignore the second)
what needs to happen in the workflow for SCCM 2012 and above is that the device needs to be added to All Systems AND the named device collection, this doesn't happen in the current setup and causes problems.
1 person found this helpful
I don't have an answer, but we are using a similar setup with SCCM 2012 R2 and VRA 6.2.3 and don't have that issue. A named collection is used on the blueprint, machine appears in the names and the All Systems without a problem, no real delays that I can see.
No need to add the All Systems in to the blueprint for us.
thanks for the reply
how long are you typically waiting for the machine to complete sccmregistration?
ours is 20-30 minutes
sometimes it will time out (despite being set to a 60 minute timeout value) and sometimes it will work. very hit and miss. would put up with it if the timeout value actually waited for 60 minutes so it always worked
The whole build is around 30 mins including installing the vra agent at the end, the sccm registration seems to be very quick as we haven't seen any delays.
We have a large SCCM deployment of around 50,000 managed machines. Being so the initial addition to the "All Computers" collection and the OSD collection can take up to 10 minutes for us. Our CM admins set the "All Computers" collection to use "Incremental Updates". (Though this may be the default setting in 2012 R2...) That's just how SCCM works... Setting the vRA SCCM timeout to 60 minutes seems to give us a 20 minute timeout.
The collection membership updates usually take around 10 minutes for us.
The complete CM install including drivers, VMware tools, vRA Agent, Windows Updates (use offline servicing!), and a few other required agents takes right around 30 minutes.
After a certain point we had to move the CM database to faster storage, that made the collection updates significantly faster, like x10. I think that dudes running on our all flash array now...
Did you get any farther with this? We are seeing a similar problem. Looks like VRealize stages the machine then forces an update to "All Systems" then continues to request refreshes over and over again on the OSD collection. Has anyone found an acceptable solution to this? Ideally I would like to prevent vRA from refreshing the All Systems collection all together considering we have a 2 minute incremental setup.
Thanks in advance.