Script fails intermittently with error 800A01AD
-
Friday, January 04, 2013 5:54 AM
A Vbscript login script is failing on the following line of code:
Set objWMIService = GetObject("winmgmts:" _
& "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")However it is intermittent and if it is run after the machine is logged on, it seems to always work fine.
Is there something in the environment that could cause this to work sometimes and not others? Any troubleshooting tips?
All Replies
-
Friday, January 04, 2013 6:39 AM
That cannot be the only line in the script. Without the whole scrip it is impossible to even guess at an answer to your question.
Happy New Year ¯\_(ツ)_/¯
-
Friday, January 04, 2013 7:24 AM
Sorry no it is not the whole script but is the line that is causing the error. The whole script is enormous.
I don't think it is a syntax issue as the whole script will run fine at certain times and usually runs fine once the machine is logged in.
I think it is more to do with a conflict with possibly something else running during login.
Just run out of ideas to troubleshoot
-
Friday, January 04, 2013 8:04 AM
Place the least number of lines in a file that ill cause the error then post them here. Anything less is not possible to use or to help you. This exercise may well allow you to find your error.
There is no reason for that line to cause an error unless there is something inn the script or in your configuration that is causing the error.
I would also wonder why you need to use WMI in a logon script.
Under all circumstances you can always connect to the local machine using WMI with GetObject unless there is a problem with WMI. Try rmoving the strComputer and replacing it with a dot.
Set objWMIService = GetObject("winmgmts:\\.\root\cimv2")
Like that.
Happy New Year ¯\_(ツ)_/¯
-
Friday, January 04, 2013 1:43 PM
I am unable to recreate the issue at will so it is hard to isolate which section I will need to include.
This is an inherited script, I don't know VBscript at all.
Are you saying that Set objWMIService = GetObject("winmgmts:\\.\root\cimv2") won't use WMI?
-
Friday, January 04, 2013 3:15 PM
Loz,
jrv is not saying that the line as changed does not use WMI. It does use WMI, but as modified will always connect to the local computer's WMI subsystem without going through network interfaces. jrv is saying "do this" because it at least lets us test for various kinds of breakage without spending hours guessing about what's wrong. Here's a quick sample of potential causes, all based on the assumption that it is always and only error 0x800A01AD that you encounter. The results of changing to "." will help bracket the real problem, with details varying based on which of the following is true:
+ the code may be trying to talk to an arbitrary machine (bad idea) or arbitrary set of machines (worse idea) in that line
+ those machines may be unavailable due to anything from normal downtime to network errors.
+ Another error in the same vein is less-than-robust machine specification in the code.
+ If all local calls anyway, networking services on the local machine may not be fully functional yet when the code is called.
IF you can be sure that you are not posting sensitive information in the code, your best bet here really is to post the code as-is. There's almost certainly no intellectual property issue - the line you post is straight-up code mechanically generated by the Scriptomatic tool, suggesting most of it is cut-and-paste. The real concern is potential security issues such as embedded credentials and information about internal architecture.
If that's an issue, your best bet is to hook up with a consultant with a solid working knowledge of WSH and WMI. With access to the original code, it should be a straightforward matter to find the cause of the intermittent problem (and possibly perform other code cleanup if desired).
- Proposed As Answer by Bill_StewartMicrosoft Community Contributor, Moderator Friday, January 04, 2013 6:39 PM
- Marked As Answer by Bill_StewartMicrosoft Community Contributor, Moderator Monday, January 07, 2013 3:47 PM
-
Friday, January 04, 2013 4:52 PM
A couple of other useful observations.
1. If this is a login script then the issue cannot be the computers access to the network.
2. Remoting to a computer using WMI during logon is very bad proctice as it can hang the logon for quite some time.
3. The OP is not a scripter and not a trained administrator so the questions is really an attempt to ask for free tech support. This forum is not a tech support resource. We can answer specific scripting questions. If you need tech support then please contact Microsoft support.
4. Things to do first. Either learn scripting and modify script to produce a full trace output or hire a consultant to modify the script for you.
5. Large logon scripts are a very bad idea and are usually the result of a system that has been managed by an untrained or inexperienced admin. Setting up a proper logon system is very important in these cases as future issues can be repeatedly difficult to remedy. (logon scripts should not generally exceed 20 to 30 lines of very basic code. Group Policy should be used to deploy sets of logon scripots taht are logically designed to meet ceratin criteria for initializing a user. All GPO related functions should be removed from all logon scripts for performance, reliability and ease of administration reasons.
Happy New Year ¯\_(ツ)_/¯
- Edited by jrvMicrosoft Community Contributor Friday, January 04, 2013 4:55 PM
-
Friday, January 04, 2013 5:10 PMModerator
If the value of strComputer is the NetBIOS name of the local computer, the statement should always work. However, it might help to specify authenticationLevel. For example:
Set objWMIService = GetObject("winmgmts:" _
& "{impersonationLevel=impersonate,authenticationLevel=Pkt}!\\" _
& strComputer & "\root\cimv2")
-----
If this fails, perhaps WMI is corrupt or disabled. Also, once the connection is made with this statement, whatever is done with objWMIService may require permissions that a normal user may not have. For troubleshooting, perhaps you can run the script after logon as a normal script. Does the script work for some users on a given computer, but not others, or is the error random (the same user somethings gets the other, not at other times)?
Finally, what is later done with the objWMIService object reference? Perhaps it can be done in other ways.
Richard Mueller - MVP Directory Services
- Edited by Richard MuellerMVP, Moderator Monday, January 07, 2013 1:11 PM Fixed typo
-
Friday, January 04, 2013 5:15 PMModerator
This is an inherited script, I don't know VBscript at all.
Then it's going to be very difficult to help you troubleshoot your problem, because any advice we offer is based on the presupposition that you're going to understand the advice. (This is a scripting forum, after all.) Even if you are an experienced script programmer, these kinds of intermittent issues can be difficult to troubleshoot under the best of circumstances. I think in your case you would be best served by hiring an experienced consultant, as Alex suggested.
jrv's advice is also pertinent, particularly #5. In most cases large logon scripts are not recommended for a long list of reasons. A qualified consultant can read through this logon script, figure out what it's supposed to do, and make appropriate recommendations.
Bill
-
Monday, January 07, 2013 5:57 AM
My apologies if it looks like I was trying to get free tech support. This is not the case and I can contact Microsoft for support, I just thought it may be useful to ask the question on a forum in case someone else had run into similar issues. After all I thought that was what forums were for.
I do script in other languages, but being an engineer, this is not my primary focus, just as tech support is not the primary focus of a programmer. That said if this is going to be as difficult as I am starting to believe, I think I better just raise this case with Microsoft.
Thanks for the input up until now, the login script is 300 lines so maybe it is time to start again.
-
Monday, January 07, 2013 6:03 AM
As an engineer then you know that the issue you pose is not a scripting issue.
If you break the script down into small logical parts and test each one you may find the issue. What you have posted so far provides absolutely no clues as to the cause. I suspect there is an error in the script logic that is sensitive to execution speed. IF you are accessing other amchinesin the scritp then you are bound to have issues at time. As an engineer you should be able to devise tests that will discover this.
Microsoft support will stick with your issue until it is resolved although they will likely also tell you to us a simplified script and will definitely require a complete script and have you run the MS diagnostics.
Happy New Year ¯\_(ツ)_/¯

