Hi,
We installed and configured the CSA last week. Now, we have the problem that we can not find updates. Unter 'System' -> 'Updates' we click on 'Scan for Updates' and get the message 'Scan Complete' but there are no updates listed. What could solve the problem?
Further information:
LANDesk Cloud Services Appliance release: dev-123
Web console version: 1.1-1.0
Gateway service version: 8.7.0.3
OS: CentOS release 6.3 (Final)
Hello All,
I have my Cloud/Gateway Appliance configured and seems to be working properly. I am just having one issue. When downloading updates it seems to take forever and a day to download updates. For example I have been watching a computer do a security scan and attempt to download a 28 MB firefox update for over an hour now. Is this normal?
Thanks,
Bryan
running Management Suite 9.5 SP 1 we are having issues connecting via the gateway on OS X clients, this is after running the uninstallagent.sh and redeploying the agent to the machine.
is there a fix for this, I've seen in other boards that SP2 may resolve the issue?
Thank you,
Mike
I was looking into building a different on-demand agent for the gateway appliance for people to access. While following the best practices sheet (https://community.landesk.com/support/servlet/JiveServlet/download/30603-17-36448/LSI%201296-Best%20Known%20Method%20for…) I was unable to locate and access the two links in the middle of "Management Gateway Console" and "Management Gateway Utilities". I am missing "Remote Control Agents" and "Software Package Upload". Please offer any advice. Thanks!
I have been working on validating the implementation of our management gateway and have run into an issue.
Currently the management gateway will function normally when updating inventories, remote control, security scans, etc. What seems to be failing though is the actual downloading of the patch files when a security scan is run. The agent communicates with the core server, gets the current security definitions, runs through the detection cycle. Then when a needed patch is detected, it fails when trying to download the actual patch files.
As this is a new implementation, I am working off the assumption that I simply missed a setting, but just don't know what it is. The message that appears in the security scan window is "Failed: could not download http://core/ldlogon/patch/updatefile". The client then proceeds to notify the core server that it could not download the patch file and then closes after the 60 second timer. The same patches that can't be download via the management gateway will download and install normally when the agent is placed back on the local network.
What did I miss and where can I look to further determine what might be the cause of the download failure?
I recently sent out instructions for Agent installation/update along with a self contained agent to my remote users. Now some remote devices are unable to run an inventory scan. They show up on the On-Demand (Waiting HTML Agents) page but do not show up under All Devices on the core.
Has anyone experienced this?
http://www.landesk.com/company/customer-product-downloads/
shows:
North and South America - MD5 Checksum: 4eb486e98312ff04756cc73b5fc59f4f
yet, I get this MD5 on "LDcsa43.exe" after downloading: 665F97977BBA2F4A46CA169A160423B1
I've downloaded it twice and used 2 different tools to verify the hash.
Does the page need to be updated or am I not checking the right file?
Is there a similar "RTC" URL for the CSA that lets you access the LDMS Web Console via the CSA? Our core server is not routed off campus so we use the CSA. I'd like our Analysts to be able to access the Web Console without having to fire up VPN.
Thanks,
Charles
I am going to be migrating my existing environment from 9.5 over to 9.6 and want to ensure that all agents have the CSA cert installed. I have read up on the configbroker and LNG file method, but my reading of that is primarily for a self contained exe agent installation for out of band cert brokering.
My plan is to discover agents in the 9.6 environment and push the new agent to the discovered machines. This, by nature, will happen in band so the configbroker method would not kick off. Would it just be a simple matter of adding a EXEC#=%DEST%\brokerconfig.exe /r in the agent INI file after the Adaptive Settings section?
Another consideration is that I will be pointing the 9.6 agents to the same CSA as the 9.5 agents and most agents will have the CSA cert. Is there any sort of stamping process that the 9.6 brokering does to the cert or will the cert put there from the 9.5 suffice?
Thanks for your help.
Hi everyone,
For compliance reasons we're required to disable SSLv2 and SSLv3 on all devices that are accessible from the Internet.
I've been looking at our Cloud Appliance, but can't see a way to disable SSLv3.
Can anyone point me in the right direction please?
Thanks,
Phil
Hello;
We use Cloud Appliance to support our remote users.
I have noticed that file Transfer is not possible while using cloud appliance to a remote computer.
I was wondering whether this is not natively supported or it has been turned of on our appliance or by the license we have.
Thanks
I noticed the number of requests and connections increase even if I have all the trusted services disabled. I checked and it looks like a number of connections on the vCSA are connecting to itself (127.0.0.1). Is this normal? Thx Mareesa
Hi I tried to get the virtual CSA 4.3 running.
I used that guide:
CSA VM installation of 4.3.pdf
Our ESX Environment:
- ESXi 5.5.0
- 16 CPUs
- 256 GB RAM
But I get this errors:
And boot stucks (for hours) here:
Has anybody better results with this?
Thank you, marco
Hi there,
I have been trying to update the CSA 4.3 with the latest patches, but every time I click on the "Scan for Updates" button it takes about a couples of seconds to show a message that says "Scan complete" and no patches are shown. As far as I recall I have never applied any patches to this CSA, so I wonder if something is wrong in the patch update. How can I know what patches if any has been applied to my CSA?
Been trying to set up the CSA but every time I try to connect a test machine to the gateway, I'll get the message:
Unable to connect to the Management Gateway
And then towards the bottom there is an error code: 14
If I try to negotiate a connection via the broker on the client machine, I get the log attached.
06:21.939 Attempting Direct HTTP connection to host QLANDESK.quirchhq.quirchfoods.com:80
06:21.939 Starting HTTP session with host QLANDESK.quirchhq.quirchfoods.com:80, proxy "", and proxy user ""
06:22.042 Unable to resolve host QLANDESK.quirchhq.quirchfoods.com address 255.255.255.255
06:22.048 Direct connection failed 6 Name resolution error
06:22.050 Using certificate file C:\Program Files (x86)\LANDesk\Shared Files\cbaroot\broker\broker.crt and keyfile C:\Program Files (x86)\LANDesk\Shared Files\cbaroot\broker\broker.key
06:22.114 Certificate/key loaded. Certificate file "C:\Program Files (x86)\LANDesk\Shared Files\cbaroot\broker\broker.crt". Key file "C:\Program Files (x86)\LANDesk\Shared Files\cbaroot\broker\broker.key"
06:22.114 Attempting management gateway connection at host QLANDESKVCS.quirchhq.quirchfoods.com and address 208.60.17.110
06:22.114 Starting HTTPS session with host QLANDESKVCS.quirchhq.quirchfoods.com, proxy "", and proxy user ""
06:22.114 Connecting to address 208.60.17.110
06:22.202 SSL Connection failed error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure 0
06:22.203 Direct connection failed, attempting to find configured proxy
06:22.317 Looking for autoproxy settings using first user who has settings; sid is S-1-5-21-796845957-1645522239-839522115-5647\Software\Microsoft\Windows\CurrentVersion\Internet Settings
06:22.318 Autoproxy settings are enabled, starting search for autoproxy
06:22.326 Sending DHCP query to determine autoproxy
06:28.334 Could not determine autoproxy from DHCP query
06:28.336 Sending DNS queries to determine autoproxy
06:28.595 DNS resolved name wpad.quirchhq.quirchfoods.com
06:28.596 Autoproxy detected in DNS: wpad.quirchfoods.com
06:28.596 Detected autoproxy path to use: http://wpad.quirchfoods.com:80/wpad.dat
06:28.596 Starting HTTP session with host wpad.quirchfoods.com:80, proxy "", and proxy user ""
06:28.596 Connecting to address 216.55.149.9
06:31.634 HTTP Request: GET /wpad.dat
06:31.635 Waiting for HTTP response
06:31.694 HTTP response finished status 200 description OK
06:31.696 Could not find proxy from autoproxy settings
06:31.697 Looking for autoproxy settings using first user who has settings; sid is S-1-5-21-796845957-1645522239-839522115-5647\Software\Microsoft\Windows\CurrentVersion\Internet Settings
Thoughts?
Didn't see any similar thread in the community so I'm posting this in a new one.
Basically I just brought up our CSA and things like Inventory Scans and remote control through the CSA work just fine. I go to test a software deployment and it bombs out with a return code of 105. I've checked the credentials to make sure that my service accounts have the proper access to the shares and they do. Just not sure what might be going on. Don't even know where to start tackling this. Any help is greatly appreciated.
Good morning all,
So I've been installing some agents manually (mostly because they aren't being picked up by the unmanaged device scan I have set up) and while the agent installs successfully, they aren't popping up on the core so that's telling me that they are not passing on the inventory scan. I grabbed on of these devices (they are all surface pro 3 tablets) and tried a couple of things. The first thing I tried was running an inventory scan manually from the client machine. I kept getting a message saying LDISCN32.EXE: the inventory server [core] did not respond. I also tried running the BrokerConfig.exe to grab a cert. While it actually connects successfully to the core, I'm unable to pull a cert using the credentials of a valid LANDesk Admin. The message I get back is "Failed to retrieve certificate". Note: I configured the agent for all of our surface pro's to connect directly to the CSA (not negotiate best connection) due to a recommendation from on of the LANDesk trainers. I've allowed access to the CSA from our local subnet (not just to the core server) to see if that would help but it does not. Any suggestions?
I have just bought an SSL certificate from GoDaddy but when I go to download the certificate I get the option to download the above servers certificate.
Does anyone know what web server I should download and apply to the CSA?
We are on the verge of deploying 9.6 and want to have the infrastructure in place to have software distributions available for people whether they are on the internal network or out on the internet.
I understand how to configure Workspace through the CSA (virtual 4.3), but the concern is where and how to house the install sources for distribution. I realize that the source path in the distribution package needs to be a web share, but that limits us to only storing installers on the core since the CSA will only communicate with the core.
We have several remote locations and do have the preferred server infrastructure set up in most of our remotes. If we set up our distribution packages to be web sourced, this will increase the load on the core server and possibly slow the installs for the remote offices because they will not draw from their preferred server. Source the distribution packages on UNC and the remotes will pull it from their preferred servers quickly, but computers out on the internet will not be able to do installs through Workspace.
Is it possible to house installers out on the cloud somewhere (say Amazon Web Share, Box, etc) and have them be accessible whether inside internal network or on the internet?
Also, we have a fair amount of exe and batch file installers that can't be distributed from a web share. Does anyone know of a way around this limitation?
Thanks.
We have a mixed environment where most of our workstations are on our domain network, while many others are off network and managed through the gateway appliance. Many of our techs continually fail to pull down broker certificates for our offline workstations during their deployment phase. I was considering building into the provisioning process just going ahead and pulling down a broker certificate on ALL workstations as a "just in case" type thing and so that we never have to depend on someone forgetting to do that extra step if a workstation is going to be going to one of our "off domain" sites. Is this bad practice, for any reason? Or is it safe to just put a broker cert on all workstations, even if most of them will be on our domain network and not be using the management gateway?