When I look in the radstate.log file (ZTIMEQ OBJECT) on a couple of computers the software connect daily is set to the following ZSCHDEF = [DAILY(19991010,00:00:00)] so the client doesn’t connect unless I force a software connection. Is there a way to reset the daily software connect time without having to reinstall the Radia 9.1 client?
Can anyone confirm or deny that there is/was a 255 path limit in the Batch Publisher? I think I remember this from long ago. It used to be a Windows problem. Now Windows addressed it, however, I think utilities still needed to be updated to work with the newer APIs. We are probably using an older version of it, so maybe it was addressed in a new release. We can likely work around it, or call it into support. Just looking to see if anyone else knows the answer off the top of their head.
Details from the error I am pretty sure because the path is over 255 for this file.
20160121 09:06:12 Error: Target <Q:/_AUTOPUBLISH/MDT_W8X64_ENT_WIN/V188.8.131.52/deployprod/Deploy/Operating Systems/Windows 8.1 Ent (x64) 2014.11.21/sources/sxs/amd64_netfx-system.directoryservices.protocols_b03f5f7f11d50a3a_6.3.9600.16384_none_3cdb1f0252010eb1/system.directoryservices.protocols.dll> does not exist
20160121 09:06:12 Error: could not read "Q:/_AUTOPUBLISH/MDT_W8X64_ENT_WIN/V184.108.40.206/deployprod/Deploy/Operating Systems/Windows 8.1 Ent (x64) 2014.11.21/sources/sxs/amd64_netfx-system.directoryservices.protocols_b03f5f7f11d50a3a_6.3.9600.16384_none_3cdb1f0252010eb1/system.directoryservices.protocols.dll": no such file or directory
Kudos goes out to the Accelerite team for quickly addressing an issue we reported. I have been a proponent for creating a less RCS intensive Patch Manager product for quite a while. When the "Patch with Metadata Only" option came out I believed this was the answer. It was actually called "Offline Scanning" or "OPUS" (no idea what that stood for) at certain points. That model downloads all the patch data needed to do discover_patch to the device so it does not have to talk to the RCS during the scanning. I had assumed that meant it would disconnect from the RCS and not be using an Active Task. We had designed our capacity around this fact. However, after troubeshooting our infrastructure issues during our production patch rollouts the last couple of months I discovered it was not working that way. It was not actually talking to the RCS, but it was still holding an Active Task and connection to the RCS during the 3~5 minutes or so it took to do discover_patch (all locally). I am referring to the Microsoft patches BTW.
Accelerite understood the issue, addressed it, and now it is already fix for the next time you do a patch acquire. I was impressed.
Long time customers may remember that a big selling point of Radia over EDM when it was first released was that EDM held the connection to the RCS (manager) during the entire connect. With Radia is was broken up so the client would connect and disconnect multiple times as to not waste resources on the server side while the client was busy doing stuff locally. We need to make sure we maintain that model. It helps us customers keep our cost down in infrastructure. I actually have an enhancement request for disconnecting during the BDELETE for similar reasons.
I have not implemented in Prod yet (it will not be until Jan patches are released), but I will repost any interesting results in reduce capacity needs after I analyze them.
During a recent Windows 10 tablet image deploying I notice slowness and found it to be related to default power scheme in WINPE which is set to balanced by default.
heres a link to a related post by deployment guys. http://blogs.technet.com/b/deploymentguys/archive/2015/03/27/reducing-windows-deployment-time-using-power-management.aspx
I am doing a little discovery of leveraging the option to use Patch Manager to patch Java (JRE specifically). I think I have every thing setup correctly. (I am currently running 9.1). However, I don't seem to be to acquire any Update after JRE 1.8 Update 31 (JRE-1-8-UPD-31). JRE is currently at update 66. Update 31 was posted on 1-29-2015. I do see some articles on the Oracle site about some change made to their patching methodology around this time.
Has anyone else experienced this? Is there a hotfix? I currently don't use this feature, so I can't say for something is broken. However, if anyone is using this feature successfully still (after 1-2015) let me know.
There was some discussion at the Radia Summit about getting Radia to not prompt for a BitLocker PIN upon reboot. I thought I would share what we do.. We basically configure a "Post Connection Script" (EXBEXIT) in COP. As part of that we run this code. It is partial and written in Winbatch but I think you will get the point. Basically, it is determining if Radia will reboot. If so, it uses the Microsoft utilities to read if PIN and TPM are enabled. If so, it runs the code to disable the PIN entry for one reboot. The only drawback that we live with is if the user cancels reboot, the PIN will not be promoted for on the next reboot (which could be a while). However, our security team was fine with the risk as the device is still encrypted, there is just no PIN for one boot.
FileWrite(hLogFile,StrCat(DateTime(),@tab,"Reboot (RADSETUP.BOOTTYPE) is ",BootType))
if BootType <> "N"
FileWrite(hLogFile,StrCat(DateTime(),@tab,"A reboot is required. Running command to determine if PIN should be disabled on next reboot"))
ManageBDE = StrCat(WinDir,"\system32\manage-bde.exe") ; Default Location for 32-bit via Radia
ManageBDE = StrCat(WinDir,"\sysnative\manage-bde.exe") ; if 64-bit, this is the location
output = GetStdOut(StrCat(ManageBDE," -protectors -get c:"))
if StrIndexNc(output,"TPM AND PIN",1,@FWDSCAN)
FileWrite(hLogFile,StrCat(DateTime(),@tab,"TPM AND PIN Found"))
RunShell(ManageBDE, "-protectors -disable c:", "", @HIDDEN, @WAIT)
FileWrite(hLogFile,StrCat(DateTime(),@tab,"Disabled PIN entry for next boot"))
FileWrite(hLogFile,StrCat(DateTime(),@tab,"TPM AND PIN NOT Found, not running command to disable PIN"))
FileWrite(hLogFile,StrCat(DateTime(),@tab,"Can not find manage-bde (key bitlocker file)"))
I want to let our users have the option to connect their laptops from home over their internet connection at night. I already use a scheduled task to wake the computers from sleep to start a connect, however, what I did not realize until recently is that the computer goes back to sleep as soon as my script ends (and I stop my script after I fire the connect). I thought Windows would just stay awake until the "sleep after x minutes" is reached. However, that is not how it work out of a scheduled task. Does anyone have a solution for this already? I am also concerned about keep the machine awake through multiple reboots, etc during the connect.
Due to the improved RCS performance (reduced load) of the “Patch Metadata Download” option on Patch Manager we implemented that model when we upgraded to Core-Sat (I think 5 years ago now). That option requires you to run the “Download Manager” which uses Apache resources instead of the CSDB resources. I must admit. I am not a big fan of this solution. I just wanted to share my experience, maybe I am overlooking something obvious. However, I had many support cases open for this in this past and I was only able to determine why we had such bad performance “out of the box” after learning a lot of Apache and the different options.
The “Download Manager” option requires a Patch Gateway, that will go out to the vendor and get the binaries. You need to pay special attention to these settings.
We have ~700 Streamline Sats that preload from our Full Service Satelitte servers. (typical). We preload the Apache patches just like we used to do when the binaries where in the CSDB.
First, the setting for “Time for which the binary is valid” in the Configuration, Distribution Settings. It by default is set to 7 days. My assumption was that after 7 days it would go upstream do a quick check and realized it already had the same file and re-stamp the date time. I was wrong, it actually downloads a fresh copy regardless if it already has a perfectly good file! This is how Apache works. That makes perfect sense of web servers with thousand of tiny files that can be easily refreshed. It does not make sense for 100 MB or greater patch binaries.
So imagine what happens when you are preloading 700 devices with say 10 GB of patches. Then every week it deletes the files and does it again!! Over and over. Complete breakdown of the process.
OK, I am not proud of this but to get around this we up the “Time for which the binary is valid” to 20 years (not a typo) on the patch gateway. We simply can’t have the file expire on all these remote locations.
Second, when you preload patches, you go against the upstream host only. There is no option to use COP. That make the flexibility of the product at a lot less and can’t use COP based bandwidth trotting.
There is no appevent reporting of patch preloads. There is not even a local “radstate” type file, you have to look in the log to if you had failures.
On the preload process there is a one hour download timeout per file!! So, if you were on a slow link with a big file, even if it was working just fine, the preload process will actually just give up and move on. It is not documented but you can configure that.
in patchgw.cfg add an “http_timeout” element with the timeout in seconds.
For now, I am sticking with this option as I believe it is the only option to reduce a big (in my opinion un-needed) load on the RCS for patch management. It has been working OK
However, I hope that in the future we can have a lightweight model that does not require the download manager / Apache.
Hi, I have an interesting issue. For any of our streamline satellites we are setting up we can access the satellite consoles from any computer in the company. When we try to access the operations and configurations tabs through the Radia Client Automation Enterprise 9.1 console we get the page can't be displayed. It's not a critical item because we can access it outside of the main console but it is quite irritating. Any ideas on what to try? Thanks for any help in advance.
Has anyone experience with the 9.2 Winoe-Build process. The process via the graphical tool Ends "succesful", but the start of this wim stops with a dosbox instead of starting the roma process.
We noticed, that the -hta files seem to be empty...
Many thanks for any hint
If any RCA agent gets removed or a desktop is formatted then the RCA agent gets removed and we cannot get any inventory or infor about the PC. Is there any mechanism in RCA that we can get alert for the removal of agent or desktop formatting.