/build/static/layout/Breadcrumb_cap_w.png

Stupid question #3: Delay at startup while "Connecting to the KBOX"

We have configured our KBOX clients to use the message "Connecting to the KBOX..." during startup. During the weeks we were getting the KBOX agents installed on our 850 machines, no users ever noticed this message.

However, since we have started creating scripts and MIs, most users are now noticing a delay when they start their machines, before the Ctrl+Alt+Del prompt and login prompt appear. During the delay the blue KBOX dialog box is displayed with the message "Connecting to the KBOX..."

This appears to be happening to all users, on all platforms, at all times of day. It varies a lot, but the typical delay might be 15-20 seconds, with a minimum of 3 seconds and a maximum of maybe 45 seconds. Maybe these times are normal?

The scripts and MIs we have created to this point are still being tested, so they are associated to very, very few machines. So it can't be just the existence (without association) of 45 scripts and 57 MIs that's causing the delay, can it?

In preparing this test environment, we've created 70 labels, 45 of which are smart labels. (No working LDAP labels yet.) Could these labels be causing the delay?

Nothing else: we have almost no patching detection or deployment enabled yet: 1-2 machines, and only a few selected patches, distributed at specific times. Only 2 custom inventory rules are configured. And we're not (yet) using File Synchronization, Virtual Kontainers, Service Desk, Dell Updates, Replication, OVAL,, Secure Browsers, or Organizations.

Or is it something else entirely? Maybe scheduling settings within scripts/MIs like "Allow Run While Logged Off" or "Also Run..."?

I know where I can check all kinds of statistics about how much time/CPU is being spent on scripts, MIs, patching, and how many clients are connected, etc. But I don't know what statistics might reveal this delay, until I have an idea what's causing the delay. I also don't know what logs to check, or how to interpret what I see there.

And, once we pinpoint the cause, the next question is: what can we do to minimize this delay?

Any guidance would be greatly appreciated. Since y'all have been using the KBOX longer than we have, you must have lots of tuning experience like this. Sande

0 Comments   [ + ] Show comments

Answers (31)

Posted by: airwolf 13 years ago
Red Belt
1
We had this problem before 5.1 was released, so it's not a 5.1 server / 5.0 client issue. I can't say whether the 5.1 agent has resolved the problem, because we moved away from running anything at logon before we upgraded to 5.1. You should be able to test this easily by upgrading one of your affected machines to the 5.1 agent.
Posted by: snissen 13 years ago
Fourth Degree Green Belt
1
Andy, you are a true treasure!

But I'm going to pester you a bit more. You mentioned, "any scripts are set to run on a system at logon". I interpret this to mean only Offline Kscripts, which can have these schedule settings:
- Also Run Once at next Client Checkin
- Also Run at Machine Boot Up
- Also Run at User Login
- Allow Run While Disconnected
- Allow Run While Logged Off

The settings that correponds to "run on a system at logon" is "Also Run at Machine Boot Up", right? Suspecting that one, I had already turned it off in all Offline Kscripts.
Sande
Posted by: snissen 13 years ago
Fourth Degree Green Belt
1
Our users tend to turn off their machines at night, so when they turn them on in the morning, they are annoyed by any delays in getting to the login dialog, especially "new" delays that appeared only recently.

So maybe I should turn off all the "Also Run" and the "Allow Run" checkboxes as well?

I'm playing with these settings because I'm trying to find a way to accomplish what I call K1st processing. This is when a machine has just received a new image, where on the first full boot (after mini-setup) or first login, we need to run a couple dozen scripts and MIs to complete the build, before the technician starts on custom installations.

I'm keying this processing on the presence of a particular JustImaged file, which triggers a custom inventory rule that results in the machine getting a K1st label. (I'm sure this makes very little sense.) Maybe I'm going about this K1st business all wrong? Is there a better way to handle everything that needs to happen on a newly imaged machine? There's a topic for your Korner: the best way to set up "1st" processing. Sande
Posted by: airwolf 13 years ago
Red Belt
1
If the scripts only need to run once for your post-image processing, then you can configure them in such a way that they will only run once:


  • At the end of the script, have it write a registry key to HKLM\YourCompany (i.e. a DWORD value of 1 for an entry named "Script1")
  • Setup Custom Inventory items to find out which machines have run each script
  • Instead of deploying the script to All Machines, setup a Smart Label filter to apply the scripts to all systems that do NOT have the script "installed" (detected by the step above)
  • NOTE: this process will, of course, require that you clear out the HKLM\YourCompany key before you create a deployment image


This will ensure that the post-image scripts will only run once on a system.
Posted by: GillySpy 13 years ago
7th Degree Black Belt
1
You can customize the behaviour of the splash screen in 5.1 by placing these variables in the SMMP.conf file. Some of them you'll have to do some scripting to "inject" them. others will get updated based on server settings

companyname // overwritten webui general setting
splashtext // overwritten client splash text define in ui
splashbitmap // path to custom bitmap for MI/FS splash screens
disablebootupsplash // do NOT show splash screen at bootup
disableloginsplash // do NOT show splash screen at login
disablewaitforbootuptasks // do NOT wait for bootup tasks to complete, fire them and continue
disablewaitforlogintasks // do NOT wait for login tasks to complete, fire them and continue


And if you're logging on to someone's machine for something quick or doing a quick reboot and don't want to reconfigure things you can one-time escape the screen with the combination Ctrl+Shift+Backspace
Posted by: cmccracken 13 years ago
Orange Senior Belt
1
Gerald,

I just tested the Disableloginsplash and Disablebootupsplash, and neither meets my need.

The variables do stop the spash screen from appearing but that doesn't make the bootup any faster, instead it leaves the user with a blue screen with no information at all as to why they can't login yet. For our users, I feel this scenario would be even worse than having the KBOX splash screen open.

I described the following test in my support ticket:

I ran the following test on a virtual machine I have that I use to build Kontainers.

1. Opened VMWare console, PC waiting at ctrl-alt-del to login.
2. Rebooted PC without logging in.
3. PC returns to ctrl-alt-del, no KBOX splash screen.
4. Log into PC as local admin user.
5. Once desktop appears, reboot PC.
6. PC returns to ctrl-alt-del after waiting for splash screen (This is the behavior I do not want).
7. Scripts currently applied to VM:
7a. Disable WSUS - Runs everyday at 10AM
7b. Configure IE - Run at User Login
8. Disable both scripts
9. Log into PC as local admin user.
10. Run ScriptRunner to apply changes.
11. Reboot PC.
12. PC returns to ctrl-alt-del after waiting for splash screen (This is the behavior I do not want).
13. Reboot PC without logging in.
14. PC returns to ctrl-alt-del, no KBOX splash screen.
15. Log into PC as local admin user.
16. Reboot PC.
17. PC returns to ctrl-alt-del after waiting for splash screen (This is the behavior I do not want).

Any help would be greatly appriciated.

Casey
Posted by: shoddinott 13 years ago
Orange Belt
1
Hi

I thought I would add something additional to this thread since I am having similar concerns. I am right at the beginning of a new kbox deployment, so I am using the current version of the back end (5.1.31237) and the agent is now one revision behind (5.3.31311). I had not seen the splash at all during or after agent deployment. The first time the splash screen was seen was after one script was configured to run on a group of machines defined by a smart label with the options 'Also Run at Machine Boot Up' and 'Also Run at User Login'selected. This caused the splash screen to display before the login prompt and/or after a user had entered their credentials. The reason for the 'and/or' in the last sentence is that sometimes it would display at boot and not after login and other times it would be the other way around.

The immediate action I have taken is to reduce the scope of the scripts deployment to only one machine and subsequently set it to run at a specific time with 'Allow Run While Disconnected' selected only. After forcing an inventory update and manually running kscriptrunner.exe I have not seen the splash screen on the single test machine after 4 reboots.

So I can only assume this has resolved the issue.

For us, this splash screen cannot be seen at all and we cannot have any additional delay at boot up or login. So the content of this thread up to now is of great concern to us.

Snissen/cmccracken, have you continued to have difficulty with this issue or have you come to a definitive resolution?

GillySpy, do you have a clear message on the expected behaviour, is my experience as designed? Am I correct in thinking that once a script scheduling is changed, the script update interval will need to pass or a manual execution of kscriptrunner will have to be carried out before these new settings apply to the client in question? What happens if the script has not yet executed using the old scheduling, must it complete the script execution by the old scheduling before the new scheduling will be adhered to?

Thanks and Regards

Simon
Posted by: cmccracken 13 years ago
Orange Senior Belt
1
Hey Simon,

We are still having difficulty with the delay on startup. I've been working with engineering, and through several debug builds of the agent, it appears that the delay is occuring when the agent queries WMI. From a test machine standpoint, I've been using a single virtual machine running XP which on average experiences a 30 second delay.

Even without one of the debug builds, you can see if you are in the same area that I am by enabling debugging, rebooting, and noting the start and stop time of your bootup splash screen. Take the start time, and look in agent.log. You should see lines that look like the following:

[2010-08-02T08:12:15] runkbot.exe 2 1276002086 BOOTUP -noLogUpload [start]
[2010-08-02T08:12:52] kbot[2:1276002086] @ 2010-08-02T08:12:52 (status) START

Notice the delay between when the bootup starts and when it really starts? That is when it is querying WMI.

If it would help, you are also welcome to reference my ticket: 76169.

Casey
Posted by: GillySpy 13 years ago
7th Degree Black Belt
1
It would be easier if I knew the settings for smmp.conf to control splash screen behaviour that is being used.

Once an offline script has been modified then you will have to wait for scripts to update on a machine. you can force this wait on a test machine by using:
runkbot 3 0

In cmccracken's case this log shows that it is running an inventory so it makes sense that it would need to query WMI. cmmcracken have you tried turning off inventory at bootup? And /or what are your smmp options.

As for expected behaviour of the splash and delay you should be able to eliminate them (within reason) by using the smmp.conf options. Make sure that you take the service offline to modify the smmp.conf file or your changes will not be picked up, or even discarded. If you are trying to limit which scripts and tasks run at bootup/ login then you will have to do that on a script-by-script basis.

The latest agent is listed here http://www.kace.com/support/customer/downloads.php The latest agent is always tested with the latest server and the release notes will clarify this. The point versions of the agent and server are not designed to match.

The best thing that will help support is if you keep track of the exact behaviour you see. e.g. if you press buton 1,2,3 then you get x. If you only have the symptoms then it is harder to track down. I'll leave the specifics for your tickets if that's okay
Posted by: shoddinott 13 years ago
Orange Belt
1
Thanks to both for the response.

For reference I have not amended any SMMP.conf settings at all, everything default.

GillySpy, I still have a little confusion here. Part of your last post seems to suggest that provided I have no managed installations or scripts set to run at bootup or user login, I will never see the splash screen or experience the delay. However another part of your last post suggests that both the splash screen and the delay may be experienced while a normal inventory task is running at bootup. For me this is about defining the expected behaviour very clearly so that it is predictable and reliable. My user base can be very 'sensitive' and therefore I must ensure that delays and splash screens are part of their expectations. Of course I would prefer that they did not exist at all (the delays and the splash screens, not the users!).

On a side note, I presume there is a reason why the custom options for the SMMP.conf are not included in the GUI?

Regards

Simon
Posted by: GillySpy 13 years ago
7th Degree Black Belt
1
Changes to the smmp.conf file are driven by scripting in this case. On 5.1 boxes there is now a script called " KBOX Agent Debug Log Enable" this is the type of script you would use to modify the smmp.conf file. Hopefully we get canned scripts to do this for the bootup flags but that's a good starting point. If anyone has a canned script they would like to share....

This is why I used the words "within reason" as there are probably some tasks, like inventory, that most customers should run at bootup. If this was a ticket I could give you more specific advice but here I have to remember that this thread may be read by other customers and read out of context.
Posted by: cmccracken 13 years ago
Orange Senior Belt
1
Hey Gerald,

My test machine is using a pretty basic SMMP:

companyname=ACSA
validationinterval=480
weburl=http://SAKBOX
log=SMMP.log
pl=pluginDesktopAlerts,pluginPatching,pluginWeb,pluginRunProcess
ampport=52230
splashtext=KBOX Agent Checking In, Please Wait...
wto=20
webport=80
lasthost=SAKBOX
crto=10
ampurl=http://SAKBOX:52230
kboxver=5.1.31237
pinginterval=30
lastvalidation=2010-08-11T17:13:51Z
host=SAKBOX
rto=20
debug=true

I never knew I could turn off the inventory on boot; is it a variable in the SMMP?

I tried the variables you mentioned in your follow up post, but they did not make a difference.

Thanks,

Casey
Posted by: JonHall 12 years ago
Senior Purple Belt
0

When we were on Kace 5.1.31821 and 5.3.47657 we didn't have this box coming up, but ever since we upgraded to 5.3.53177 there's a delay after hitting ctrl/alt/del to login. Has anybody seen this annoyance fixed and then returned with the latest update?

Thanks, Jon


Comments:
  • JohnHall

    I have not had any issues with the splash up to this point. Any manual installs have not resulted in any splash screen. I did a test update using KBOX pushing the new agent because most of my agents are 5.1 so I updated to to 5.3.5177 and any of those updates did result in a splash page.

    Not sure if you resolved your issues but I used the advice from GillySpy on 8/17/10:

    net stop "Dell KACE Agent"

    add the following to your amp.conf file

    disablebootupsplash=yes
    disableloginsplash=yes
    disablewaitforbootuptasks=yes
    disablewaitforlogintasks=yes

    net start "Dell KACE Agent"

    And now my issues with the splash screen is gone .... YAY!!!
    No more whinning .... :) - thewuzzles 11 years ago
Posted by: snissen 13 years ago
Fourth Degree Green Belt
0
To put it another way, here's what I'm asking:

When this blue "Connecting to the KBOX" dialog box displays at startup, what exactly is the agent doing at that time? (As opposed to what it's doing at other times, like after user login.)

How long does this normally take?

And what KBOX objects or their settings could affect what the agent is doing at that time? Sande
Posted by: airwolf 13 years ago
Red Belt
0
This delay and splash screen will appear if any scripts are set to run on a system at logon. There isn't any way to bypass it that I know of. As a result, we've had to setup custom filters to only run scripts on systems that haven't already run them (writing registry keys for smart filter detection). If a script is supposed to always run, we setup a time delay (i.e. run every 2 hours instead of at logon). The splash screen is annoying, and we've just migrated to not using scripting at logon for anything.
Posted by: snissen 13 years ago
Fourth Degree Green Belt
0
Does it matter that we're still using the latest 5.0 agents, though we've fully upgraded our server to 5.1?

(There's a problem with the newer Mac agents corrupting the login hook when they install, so we've postponed agent upgrades for now.)
Posted by: airwolf 13 years ago
Red Belt
0
Yes, I'm referring to Offline KScripts. At Machine Bootup shouldn't cause any problems, because they'll run in the background whether someone is logged in or not. I suppose they could cause delay if someone logs on immediately after booting up a system.
Posted by: snissen 13 years ago
Fourth Degree Green Belt
0
I just found the report named, "Boot/Login Policies". This is right on point.

This and the other reports categorized as KBOX will help me figure out where I have a problem. Sande
Posted by: airwolf 13 years ago
Red Belt
0
This is fantastic, Gerald! Are these settings documented anywhere? They will definitely come in handy for me!
Posted by: GillySpy 13 years ago
7th Degree Black Belt
0
No they are not documented. I've seen some anomalies with them not getting retained in the smmp.conf file if the connection settings are changed so use them with that caveat for now.
Posted by: cmccracken 13 years ago
Orange Senior Belt
0
Hey Sande,

I'm having the same trouble you described. I put a support ticket in, and my tech recommended the variables above, but on my test machine they didn't make a difference. I've sent him my SMMP to make sure I used the variables correctly, but in the mean time I wanted to see how your fix was going.

Casey
Posted by: snissen 13 years ago
Fourth Degree Green Belt
0
Casey, I don't have a fix. Users are just getting used to seeing these blue dialog boxes, and are blaming the delays on the #$&!@^% KBOX.

BTW, we are now experimenting with patching, and it doesn't make the startup delays any worse. Of course, patches don't usually run at that time... Sande
Posted by: cmccracken 13 years ago
Orange Senior Belt
0
Hey Sande,

So far I haven't found a fix either and the user complaints are gettings louder.

If I find anything I'll keep you posted.

Casey
Posted by: GillySpy 13 years ago
7th Degree Black Belt
0
i ran a quick test adding Disableloginsplash as the last line in the smmp.conf and that worked for me. My test startup script ran but I did not see the login splash screen when the flag was there.

Make sure you shutdown the KBOXSMMPService (sc stop KBOXSMMP), edit the file and then restart the service. Also make sure you are on 5.1 AP agent.

If it's not working as expected then the right thing to do is definitely open a ticket and we can leave the troubleshooting to that.
Posted by: snissen 13 years ago
Fourth Degree Green Belt
0
I agree with Casey. If there is going to be a delay, I want a splash screen that gives the user some idea that something is happening. I don't care about the splash screen--I care about the delay!
Posted by: GillySpy 13 years ago
7th Degree Black Belt
0
P.S. to casey as I didn't read all the way up last time

What about using all 4 of these to speed it up:

disablebootupsplash
disableloginsplash
disablewaitforbootuptasks
disablewaitforlogintasks


Does that not work?
Posted by: shoddinott 13 years ago
Orange Belt
0
Hi GillySpy

Thanks for the response. I do actually have a ticket open for this - 83828. Could I perhaps get 10 minutes of your time tomorrow? I just need some very specific questions cleared up and I should have the information I need. Feel free to email me directly from the ticket.

Thanks

Simon
Posted by: cmccracken 13 years ago
Orange Senior Belt
0
Hey Guys,

Wanted to give you an update. The latest information I had from my ticket was that engineering is hoping to fix this problem with the next agent release (5.2), ETA beginning of the year. I've requested to be part of the beta release, and you probably could also join in. Has anyone come up with any other work arounds? We have been experiencing the delay for several months, but I still receive regular compaints. I'd also be interested in knowing how many others have the same problem. It would seem odd (to me) if only a few of us experienced it.

Casey
Posted by: shoddinott 13 years ago
Orange Belt
0
Hi Casey

From my perspective I have just avoided the use of anything that is known to cause the issue. Obviously this means we have compromised some of the abilities the kbox has. Unfortunately there is no way I will be able to explain to my user community how such a delay will be 'benefitting' them. If it doesn't get resolved then I suspect alternative products will be sought.

As far as beta release participation goes, I'm glad you are prepared to take part. Not something for me to get involved in..

Simon
Posted by: cmccracken 13 years ago
Orange Senior Belt
0
Hey Simon,

What features have you avoided? At this point, I'm willing to cut back on whatever I need in order to kill the delay.

Thanks,

Casey
Posted by: thumbsupy 12 years ago
Senior Yellow Belt
-1
Hi.

A year has gone, whats the status on this issue? I olso has this problem, using agent ver. 5.1.38724....
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ