Hey, Scripting Guy! Quick-Hits Friday: The Scripting Guys Respond to a Bunch of Questions (04/10/09)

Troubleshooting a Script for Setting “Managed By” and “Managers Can Update Members List” Fields


Hey, Scripting Guy! Question

Hey, Scripting Guy! I have been working for a few weeks on creating a Windows PowerShell script for setting the “Managed By” field and the “Managers can update members list”. I know the managers must be granted WriteMembers Allow property, but cannot find how to do this. Setting the WriteProperties Allow property does not work for us for several reasons. The first is that the “Managers can update members list” check box does not get selected. Secondly, they are granted too much access. My script has become very lengthy and this is only one small part of the script. This is important because this is the only thing keeping me from saving my team literally hundreds of hours a month in creating and securing folders. Please help.

– JB

Spacer Hey, Scripting Guy! Answer

Hi JB,

I decided to pass your question over to Brandon who is a Microsoft MVP for Windows PowerShell. He came up with this cool script.



How Can I Add a Network Drive for a User?


Hey, Scripting Guy! Question

Hey, Scripting Guy! Can you please help me out? I want to add a network drive for a user. The script works as a logon script, but if the drive is already there, the user gets an error message. Can you help me streamline the script, to avoid the errors? Here is the script so far.

– RJ

Spacer Hey, Scripting Guy! Answer

Hi RJ,

We need to create a dictionary object to hold all the drives and their current mappings. We will then use the WshNetwork object (wscript.network) to allow us to enumerate and to create the drive mappings. Next we use the count property to walk through the drive mappings. This is returned as an array of drive mappings. The even drive mappings contain the case sensitive drive letter, and the odd ones are the resource (strange I know, but that is how it works.) We then use the exists property to see if a drive actually exists, and either print out the fact that the drive exists or else create a new drive mapping for the resource. We then print out the contents of the dictionary object. A good book for beginners on VBScript is the MSPress book, Microsoft VBScript Step by Step.

Top of page Top of page

How Can I Pull Information from Each Workstation on the Network, Regardless of Whether the Workstation is On or Off?


Hey, Scripting Guy! Question

Hey, Scripting Guy! I have a question that is troubling me for some time and I am about to go crazy. What I am trying to do is pull information—let’s say the amount of RAM installed—from each workstation on our network. I wrote a script that works fine if all computers are up on the network. The problem I am having is that when the script tries to check a computer that is either off or not connected to the network, it gives me the previous computer’s information. Can you help me figure out what in the world I am doing wrong?

When I run the above code, I get the following output:

– NB

Spacer Hey, Scripting Guy! Answer

Hi NB,

Wow, thank you for a cool script! This is awesome. Your problem is that you are using On Error Resume Next. On Error Resume Next can really play tricks with you if you are not careful. On the Script Center we have it on lots of examples (and in the Scriptomatic) not as a best practice, but as an expedient. As you have found out, there is a huge difference between a script that runs locally on you laptop, and one that you expect to put into production and use across a heterogeneous distributed enterprise network. On your laptop you completely control your environment (OS version, service pack level, software patches, firewall configuration, services, and running processes), but on a far-flung server stuck under someone’s desk on the other side of the world, you may not immediately know all that information. To ensure that the script runs, we either make queries that determine the exact environment and handle the various exceptions specifically in code, or we simply “cheat” and use On Error Resume Next. Depending on what we are attempting to do, there is absolutely nothing wrong with using On Error Resume Next, but only if you know what you are doing and what the exact results of the operation will be if it fails. Let us tell you a true story. We have this friend named Korf (it is his nickname, not actual name). One time he wrote a script that did the following:

Now on the day he intended to do his data migration, he ran the script. The problem is there was an IP address conflict, and when the script ran, he was unable to connect to Server B. At the top of his script was, well you have already guess it, On Error Resume Next. So when the script ran, this is what happened:

So as you can see, the only thing that was successful was the deletion of the original files and folder. No copy was made. Luckily, my friend Korf had a backup of the directory, but it could have been a disaster instead of the minor inconvenience that it was.

Ok, so let’s get back to the problem with your script. When all the computers are up and running, everything works. The problem arises when one of the computers is down. You see the results with inaccurate results. In your script, the first line fails because WMI is unable to make a connection to the remote computer. The second line fails because the ExecQuery command fails because there is not a WMI object (as a result of the first line failing). Therefore, the value that is contained in the variable colItems never gets updated. The two lines of code that fail are seen :

Now we get to the part of the script that works, and that is the Wscript.Echo portion seen here. Because both colItems and objItem still have their old values from the previous running of the script, you end up with the old data being reported for the current computers memory value.

One way to fix this is to release the values of the variables between loops. You can set the variable to nothing. You will need to make this change between the two next statements. The revised script would look like 


“But wait a minute,” you may exclaim, “you are still using On Error Resume Next, and you just got done with a fifteen-minute diatribe, complete with examples, against the use of On Error Resume Next.” Yes, you are correct. Good catch! My point was that On Error Resume Next will mask problems and at times even cause problems or unintended consequences. The script will fail if we remove On Error Resume Next and a computer is down. The better way to do this is to recast the script, and test for connectivity by using a ping command. As the script is written now, it could hang indefinitely if the remote computer is inaccessible. This would be because of problems with DCOM. This article talks about testing connections to remote computers, and handling the resultant errors.


How Can I Wake Up and Then Close a Network Drive?


Hey, Scripting Guy! Question

Hey, Scripting Guy! On occasion, a network drive goes to sleep on me, so I poke it with a script to awaken it. I then want to close it soon after and not leave it open. Here is the script I use to wake up my network drive:

– MB

Spacer Hey, Scripting Guy! Answer

Hi MB,

You need to dereference your variable. The Shell.Application object is talked about on MSDN, but there is no close method. Here is an example of doing what you wish:


This brings us to the end of this week’s Quick-Hits Friday and another week on the Script Center. It should be a very nice weekend, so get out there and enjoy the weather. We will see you next Monday. Until then, take care.


Ed Wilson and Craig Liebendorfer, Scripting Guys


No Comment.