I know that this has been a continuous issue with the KACE agent, and I've been hearing all the problems that have been happening.
I have spent quite a bit of time working with KACE support to resolve them, and we have finally come up to a few solutions, that I'm hoping will make the KACE agent installation much more reliable, and check-ins much more consistent.
Problems found:
1- Some workstations were using the Intermediate SSL certificate, to connect to the KBOX, and that certificate was not correctly imported into KACE, even though I had imported it on setup, but it never stuck, because DigiCert had supplied me with the wrong intermediate certificate. So, gotta blame digicert on that one... Who knew...
2- The agent was setup so as to direct all agent communication traffic to port 443 (SSL). The KACE box has the ability to redirect any port 443 to port 80 if port 443 is inaccessible (due to a bad certificate, for instance). because we had the auto redirect enabled to port 443, any traffic that would fall back to port 80, would immediately attempt to get redirected back to port 443, and the agent would get stuck in an infinite loop, without ever establishing a communication path with the KBOX.
3- The UAC was causing major problems with authentication as a different user, due to the auth tokens being restricted by UAC when being run through a msiexec engine as a silent installer.
Solutions Implemented:
1- I have gotten the correct Intermediate certificate from DigiCert, and uploaded it to the KBOX. This time, it stuck, and the machines that were having trouble checking in (that I was working on) , immediately checked in.
2- I have disabled the auto redirect to port 443. This will actually allow an agent to check-in over a non-SSL channel. Now that we have taken care of the root of the SSL problem, there shouldn't be any issues with the client connecting over port 443, but I did it this to maximize the checkin rate of the clients.
3- In reading regarding the installation of the KACE agent on the knowledge-base, it is recommended to turn off UAC.
I have gone ahead and turned it off on the STUDENT2 domain, and will wait till the weekend to turn it off on CVUSD. The reason for that, is because if that policy is changed mid day, as soon as it applies, the user will get a pop up informing them that they would need to reboot their machine before UAC can be turned off. If the machines are turned off during the weekend when we make this change. Most computers will just boot up on monday and grab the new policy without any notification to the user.
What to expect: (If things work like I expect them to)
- A much higher check-in rate to the KBOX, where the machine gets its inventory and gets populated there.
- The swinstall should get a better success rate in running, as it will have the necessary privileges to execute correctly.
For any questions or concerns, please contact me .
I have spent quite a bit of time working with KACE support to resolve them, and we have finally come up to a few solutions, that I'm hoping will make the KACE agent installation much more reliable, and check-ins much more consistent.
Problems found:
1- Some workstations were using the Intermediate SSL certificate, to connect to the KBOX, and that certificate was not correctly imported into KACE, even though I had imported it on setup, but it never stuck, because DigiCert had supplied me with the wrong intermediate certificate. So, gotta blame digicert on that one... Who knew...
2- The agent was setup so as to direct all agent communication traffic to port 443 (SSL). The KACE box has the ability to redirect any port 443 to port 80 if port 443 is inaccessible (due to a bad certificate, for instance). because we had the auto redirect enabled to port 443, any traffic that would fall back to port 80, would immediately attempt to get redirected back to port 443, and the agent would get stuck in an infinite loop, without ever establishing a communication path with the KBOX.
3- The UAC was causing major problems with authentication as a different user, due to the auth tokens being restricted by UAC when being run through a msiexec engine as a silent installer.
Solutions Implemented:
1- I have gotten the correct Intermediate certificate from DigiCert, and uploaded it to the KBOX. This time, it stuck, and the machines that were having trouble checking in (that I was working on) , immediately checked in.
2- I have disabled the auto redirect to port 443. This will actually allow an agent to check-in over a non-SSL channel. Now that we have taken care of the root of the SSL problem, there shouldn't be any issues with the client connecting over port 443, but I did it this to maximize the checkin rate of the clients.
3- In reading regarding the installation of the KACE agent on the knowledge-base, it is recommended to turn off UAC.
I have gone ahead and turned it off on the STUDENT2 domain, and will wait till the weekend to turn it off on CVUSD. The reason for that, is because if that policy is changed mid day, as soon as it applies, the user will get a pop up informing them that they would need to reboot their machine before UAC can be turned off. If the machines are turned off during the weekend when we make this change. Most computers will just boot up on monday and grab the new policy without any notification to the user.
What to expect: (If things work like I expect them to)
- A much higher check-in rate to the KBOX, where the machine gets its inventory and gets populated there.
- The swinstall should get a better success rate in running, as it will have the necessary privileges to execute correctly.
For any questions or concerns, please contact me .
- This change was made on 04/20/2011 @ 11:00am
- Other changes will be applied over the weekend (Turning of UAC on the CVUSD domain)
No comments:
Post a Comment
Please make your comment. (GMK)
Note: Only a member of this blog may post a comment.