How To Stop Users Cancelling Updates
I have organised almost 20 different updates now, which rollout via the login script and individual batch files when users log in to the Novell file server.
This all works fine, no adverse side effects, all good.... Except one thing (as always) the user [:@]...
The updates are delivered via login script as I say, the downside is that the command box that pops up has the standard 'X' in the top right corner which is allowing the users to cancel the update, causing a mirade of problems. Also one or two of them have realised that CTRL+C cancels the batch file.
So I am asking, does anyone know if there is a way for the 'X' in the command prompt to be removed or simply ignored by the PC?
- PC environment is a mix of Windows 2000 Pro SP4 and Windows XP Pro SP2.
Regards
Darkmarauder
This all works fine, no adverse side effects, all good.... Except one thing (as always) the user [:@]...
The updates are delivered via login script as I say, the downside is that the command box that pops up has the standard 'X' in the top right corner which is allowing the users to cancel the update, causing a mirade of problems. Also one or two of them have realised that CTRL+C cancels the batch file.
So I am asking, does anyone know if there is a way for the 'X' in the command prompt to be removed or simply ignored by the PC?
- PC environment is a mix of Windows 2000 Pro SP4 and Windows XP Pro SP2.
Regards
Darkmarauder
0 Comments
[ + ] Show comments
Answers (1)
Please log in to answer
Posted by:
anonymous_9363
16 years ago
It's a standard DOS box controlled by the login process so, practically speaking, you cannot control what furniture it uses.
Ways to tackle errant users:
- Log the successful completion of updates and publish the names of persistent 'cancellers' (if only to their managers)
- It isn't unknown for an IT department to make a point by faking some security issue and publicly blaming a user's non-updated workstation as the source. No names, no pack drill...LOL.
- Immediately switch control of the update process to a home-grown service EXE. They're easy enough to author: you could, if desperate, take your update batch file (I presume it's a separate file), use one of the many BAT-to-EXE tools to create an EXE, then use SRVANY to turn it into a service. Less than optimal but a QAD solution.
- Although not designed for this purpose, I suppose you could use Active Setup. The downside is that it will execute for every user who logs in to each machine, although that may not be an issue in your environment.
Ways to tackle errant users:
- Log the successful completion of updates and publish the names of persistent 'cancellers' (if only to their managers)
- It isn't unknown for an IT department to make a point by faking some security issue and publicly blaming a user's non-updated workstation as the source. No names, no pack drill...LOL.
- Immediately switch control of the update process to a home-grown service EXE. They're easy enough to author: you could, if desperate, take your update batch file (I presume it's a separate file), use one of the many BAT-to-EXE tools to create an EXE, then use SRVANY to turn it into a service. Less than optimal but a QAD solution.
- Although not designed for this purpose, I suppose you could use Active Setup. The downside is that it will execute for every user who logs in to each machine, although that may not be an issue in your environment.
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.
