All dancing single or separate scripts?

[TechSupp]

Been battling all day with my new printer\drive maping script. One minute it works, the next it only maps half the drives! If I then browse to the script directory and run the script it works perfectly!

 

Now...I have all this going on in one script but is that the problem and should I do them as separate scripts i.e. set_printers and set_drives etc. At one of the other schools I had to do this and it works fine, yet at another (they don't have folder redirection going on) it works as a single file.

 

So my questions are:

1. Should I use separate scripts

2. Is it the folder redirection that is messing with the processing of the scripts at the same time

 

3.As a final problem one of the printers reports in light grey writing under the printer icon (where it gives its status) Access denied, etc, yet if I select it in a program it prints fine :?

 

4. Why oh why did I go into work today!

 

PS The original setup was a couple of batch files. I have deleted them from the Pupils and Teachers GPO logon/off properties, but would they also be located anywhere else i.e. on a global GPO? Where should I check?

[Ric_]

The original batch files may have been called from teh users' properties pages... may be worth a check.

 

Personally, I would have two scripts to do what you are trying anyway. By keeping these two distinct scripts separate there is less to go wrong and makes editting and troubleshooting easier. There shouldn't be a performance hit and GPOs are perfectly happy having several scripts defined for logon.

[Joedetic]

Ric_ is right. Separate scripts make it easier to see what's going wrong.

 

However, if you /do/ decide to lump them into one super-script make sure it's commented well, that way it's going to help when it comes to editting etc.

 

With regards to the printer problem. Could it be a permissions thing? IE: being able to print to but not edit properties of the printer?? (*makes stab in the dark*

[tom_newton]

Unix philosophy: Do one job and do it well

 

If you have loads of little tools rather than one super-swiss-army-knife, you can "chain" them in different ways, and put them together differently to do different things later. You'll thank yourself later for keeping things separate.

[maniac]

I have mine as seperate scripts, 3 in total, 1 for drive mapping, 1 for printer mapping, and 1 that does other misc tasks.

 

If they've VB scripts, one of the common problems (particlarly with drive mapping) is the script executing before the user is properly logged on, therefore being unable to map the drives as the user isn't properly authenticated to the server yet.

 

To solve this problem, it is possible to put a small loop in the script that only exits once the user is logged on. Simple but effective! (worked for me)

 

Mike.

[TechSupp]

Thanks All,

Went in this morning with the script broken down into separate ones i.e. Map_drives, Map_printers etc, loaded them up and hey presto worked first time and every time

 

So just had time by the end of the day to leave a little message for the staff to arrive to on Monday,

 

"All school PC's out of use till lunchtime"

 

Give me time to finish off all the other little bits that did'nt get done today.

 

P.S. The printer message was an rights issue (now sorted).

[srochford]

PS The original setup was a couple of batch files. I have deleted them from the Pupils and Teachers GPO logon/off properties, but would they also be located anywhere else i.e. on a global GPO? Where should I check?

 

You don't say which version of Windows server you're running but if it's 2003 then you can use the Group Policy Management Console to find out what's where.

 

One thing that's really useful is modelling - it lets you see what policies will apply to any user on any computer (details at http://technet2.microsoft.com/WindowsServer/en/library/be2c2744-15f4-4495-9ae7-19ee3c9da70d1033.mspx?mfr=true)

 

If you don't have many GPOs but you don't know where they're applied (eg if you have one GPO which contains the logon script but it's applied at lots of different levels) then you can also use the tree view to see what's connected where - click at the top of the domain and press the * key to expand all the way down. You can then quickly see what's going on.