Iterations
Windows Server Forum Index Windows Server
Server discussion on Windows platform.
 
 FAQFAQ   MemberlistMemberlist     RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 
 
Google
 
Web winserverhelp.com
Iterations

 
Post new topic   Reply to topic    Windows Server Forum Index -> Programming
Author Message
stev379
Guest





Posted: Tue Dec 28, 2004 6:21 pm    Post subject: Iterations Reply with quote

I'm building a script to find and log specific file names on a PC. The way I
would do it now is just to rewrite the logging portion. I think there is a
way to loop and have it count through so it uses a different file name each
time.How can I set it so it will go through iterations by the file names?
So if the filenames were "filename1, filename2, filename3 etc.", it may use
somethinglike
filename0 (0)
filename1(1)
filename2(2)

'My current example with just rewritting the script over an over:
LogFile = "C:\Testing.txt"
Set f = objFSO.OpenTextFile(LogFile, ForAppending, True)
If objFSO.FileExists("C:\filename0.exe")=True Then
f.WriteLine Now & ";" & WshNetwork.ComputerName & ";" & "Success" & ";" &
Err.Description
Else
f.WriteLine Now & ";" & WshNetwork.ComputerName & ";" & "Failure" & ";" &
Err.Description
Err.Clear
End If

If objFSO.FileExists("C:\filename1.exe")=True Then
f.WriteLine Now & ";" & WshNetwork.ComputerName & ";" & "Success" & ";" &
Err.Description
Else
f.WriteLine Now & ";" & WshNetwork.ComputerName & ";" & "Failure" & ";" &
Err.Description
Err.Clear
End If

'End script

Thanks for any help or suggestions!
-Steve
Back to top
Al Dunbar [MS-MVP]
Guest





Posted: Tue Dec 28, 2004 11:15 pm    Post subject: Re: Iterations Reply with quote

"stev379" <stev379@discussions.microsoft.com> wrote in message
news:B393ED58-6E39-4022-9C9C-B88DE08A97F5@microsoft.com...
Quote:
I'm building a script to find and log specific file names on a PC.

According to what you write below, you are not looking for specific
filenames so much as specific files, as you are looking only in the root
folder. Perhaps if you gave some details about what it is you want to do
when you find these files in existence, there might be a way to get closer
to your intended result than to just provide a list of which files exist and
which don't.

Quote:
The way I
would do it now is just to rewrite the logging portion. I think there is
a
way to loop and have it count through so it uses a different file name
each
time.How can I set it so it will go through iterations by the file names?
So if the filenames were "filename1, filename2, filename3 etc.", it may
use
somethinglike
filename0 (0)
filename1(1)
filename2(2)

Method 1:

filenames = array( _
"lions.txt", _
"tigers.txt", _
"bears.txt", _
"Oh my!.txt" _
)

for each filename in filenames
' your code goes here
next

Method 2:

call filecheck("lions.txt")
call filecheck("tigers.txt")
call filecheck("bears.txt")
call filecheck("Oh my!.txt")
wscript.quit

sub filecheck(filename)
' your code goes here
end sub

Quote:
'My current example with just rewritting the script over an over:
LogFile = "C:\Testing.txt"
Set f = objFSO.OpenTextFile(LogFile, ForAppending, True)
If objFSO.FileExists("C:\filename0.exe")=True Then
f.WriteLine Now & ";" & WshNetwork.ComputerName & ";" & "Success" & ";" &
Err.Description
Else
f.WriteLine Now & ";" & WshNetwork.ComputerName & ";" & "Failure" & ";" &
Err.Description
Err.Clear
End If

If objFSO.FileExists("C:\filename1.exe")=True Then
f.WriteLine Now & ";" & WshNetwork.ComputerName & ";" & "Success" & ";" &
Err.Description
Else
f.WriteLine Now & ";" & WshNetwork.ComputerName & ";" & "Failure" & ";" &
Err.Description
Err.Clear
End If

'End script

Thanks for any help or suggestions!
-Steve
Back to top
stev379
Guest





Posted: Tue Dec 28, 2004 11:41 pm    Post subject: Re: Iterations Reply with quote

This is pointing me in the correct direction.
My users tend to invite a lot (very very much) of spyware. I'm finding new
things everyday that most spyware/adware removal tools don't cover. I'd like
to build this portion of the script to go through an array of files, and
delete them, such that I can easily add to the list without having to edit
large portions of a script for each file.

Due to my organizations policies, politics and language barriers, training
the users to not drag their feet as they browse the web is not a viable
option.

I enjoy building such scripts in my free time and figure I can learn along
the way.

Thanks again for any more help you can offer.

"Al Dunbar [MS-MVP]" wrote:

Quote:

"stev379" <stev379@discussions.microsoft.com> wrote in message
news:B393ED58-6E39-4022-9C9C-B88DE08A97F5@microsoft.com...
I'm building a script to find and log specific file names on a PC.

According to what you write below, you are not looking for specific
filenames so much as specific files, as you are looking only in the root
folder. Perhaps if you gave some details about what it is you want to do
when you find these files in existence, there might be a way to get closer
to your intended result than to just provide a list of which files exist and
which don't.

The way I
would do it now is just to rewrite the logging portion. I think there is
a
way to loop and have it count through so it uses a different file name
each
time.How can I set it so it will go through iterations by the file names?
So if the filenames were "filename1, filename2, filename3 etc.", it may
use
somethinglike
filename0 (0)
filename1(1)
filename2(2)

Method 1:

filenames = array( _
"lions.txt", _
"tigers.txt", _
"bears.txt", _
"Oh my!.txt" _
)

for each filename in filenames
' your code goes here
next

Method 2:

call filecheck("lions.txt")
call filecheck("tigers.txt")
call filecheck("bears.txt")
call filecheck("Oh my!.txt")
wscript.quit

sub filecheck(filename)
' your code goes here
end sub

'My current example with just rewritting the script over an over:
LogFile = "C:\Testing.txt"
Set f = objFSO.OpenTextFile(LogFile, ForAppending, True)
If objFSO.FileExists("C:\filename0.exe")=True Then
f.WriteLine Now & ";" & WshNetwork.ComputerName & ";" & "Success" & ";" &
Err.Description
Else
f.WriteLine Now & ";" & WshNetwork.ComputerName & ";" & "Failure" & ";" &
Err.Description
Err.Clear
End If

If objFSO.FileExists("C:\filename1.exe")=True Then
f.WriteLine Now & ";" & WshNetwork.ComputerName & ";" & "Success" & ";" &
Err.Description
Else
f.WriteLine Now & ";" & WshNetwork.ComputerName & ";" & "Failure" & ";" &
Err.Description
Err.Clear
End If

'End script

Thanks for any help or suggestions!
-Steve


Back to top
Al Dunbar [MS-MVP]
Guest





Posted: Wed Dec 29, 2004 3:36 am    Post subject: Re: Iterations Reply with quote

"stev379" <stev379@discussions.microsoft.com> wrote in message
news:5D5EF6F8-23DC-4AA3-A56B-C04DA192F661@microsoft.com...
Quote:
This is pointing me in the correct direction.
My users tend to invite a lot (very very much) of spyware. I'm finding
new
things everyday that most spyware/adware removal tools don't cover. I'd
like
to build this portion of the script to go through an array of files, and
delete them, such that I can easily add to the list without having to edit
large portions of a script for each file.

Ok, so if you want to delete the files, are you sure that that will fix the
problem? Perhaps the contents have already been installed, and the file is
only an artifact.

A few things to think about:

- what O/S's run on your clients? If w2k XP and up, then I would recommend
that, instead of running this code at each individual workstation that you
run it from an admin workstation. There are a number of ways that this could
be done...

- are you expecting to remain current by adding to your "bad-file" list only
what you run across and personally verify as malware? I would recommend
investigating various packages that can do this a little more automatically
for you.

- are you expecting to safely continue to detect bad files simply by the
filenames they arrive in?

Quote:
Due to my organizations policies, politics and language barriers, training
the users to not drag their feet as they browse the web is not a viable
option.

Agreed. But even in the simplest of environments, relying on user training
as the primary defence against adware is foolhardy.

Quote:
I enjoy building such scripts in my free time and figure I can learn along
the way.

There is no way you can script without learning something. I would only warn
you that you need to put more emphasis on the task of protecting your
infrastructure than on the importance of being the one to save the day with
scripting.

/Al


Quote:
Thanks again for any more help you can offer.

"Al Dunbar [MS-MVP]" wrote:


"stev379" <stev379@discussions.microsoft.com> wrote in message
news:B393ED58-6E39-4022-9C9C-B88DE08A97F5@microsoft.com...
I'm building a script to find and log specific file names on a PC.

According to what you write below, you are not looking for specific
filenames so much as specific files, as you are looking only in the root
folder. Perhaps if you gave some details about what it is you want to do
when you find these files in existence, there might be a way to get
closer
to your intended result than to just provide a list of which files exist
and
which don't.

The way I
would do it now is just to rewrite the logging portion. I think there
is
a
way to loop and have it count through so it uses a different file name
each
time.How can I set it so it will go through iterations by the file
names?
So if the filenames were "filename1, filename2, filename3 etc.", it
may
use
somethinglike
filename0 (0)
filename1(1)
filename2(2)

Method 1:

filenames = array( _
"lions.txt", _
"tigers.txt", _
"bears.txt", _
"Oh my!.txt" _
)

for each filename in filenames
' your code goes here
next

Method 2:

call filecheck("lions.txt")
call filecheck("tigers.txt")
call filecheck("bears.txt")
call filecheck("Oh my!.txt")
wscript.quit

sub filecheck(filename)
' your code goes here
end sub

'My current example with just rewritting the script over an over:
LogFile = "C:\Testing.txt"
Set f = objFSO.OpenTextFile(LogFile, ForAppending, True)
If objFSO.FileExists("C:\filename0.exe")=True Then
f.WriteLine Now & ";" & WshNetwork.ComputerName & ";" & "Success" &
";" &
Err.Description
Else
f.WriteLine Now & ";" & WshNetwork.ComputerName & ";" & "Failure" &
";" &
Err.Description
Err.Clear
End If

If objFSO.FileExists("C:\filename1.exe")=True Then
f.WriteLine Now & ";" & WshNetwork.ComputerName & ";" & "Success" &
";" &
Err.Description
Else
f.WriteLine Now & ";" & WshNetwork.ComputerName & ";" & "Failure" &
";" &
Err.Description
Err.Clear
End If

'End script

Thanks for any help or suggestions!
-Steve


Back to top
stev379
Guest





Posted: Wed Dec 29, 2004 5:03 am    Post subject: Re: Iterations Reply with quote

Agreed to all.
Understanding the manner in which this particular task can work, will help
me build the other scripts I'm tying in with this project.
Stopping processes
Deleting reg values
unregistering dll's
Deleting reg keys
Deleting temp files
Correcting any system config changes
logging
And anything more that may be needed.

95% of the OS's on the machines with issues are 2k and XP


I plan to stay as current as needed. We run a report about 1 per month that
lists known issues found on infected machines. We don't have, and they
won't purchase every spyware/adware removal program that is available. It's
getting so that is what one needs to do in order to completely clean a badly
infected machine. It gets time consuming manually removing them. This all
being said, I do and will continue to use various spyware programs that we do
have (Spybot, Adaware, cwshredder, HiJack This...etc.)

Unfortunately the way the organization I work for is structured, I'm
currently only able to cover issues from my level (at the user’s local
workstation, which is not what the job description was...). Until I'm able
to correct this..., I'd like to enjoy my time and give my mind something to
do when I'm sitting at my own desk.

I really don't care much about "being the one to save the day". My
organization is large enough that this won't matter to anyone but me. This
is just to make my time more pleasant and productive when I go on these calls
and help me learn more about scripting.

Were this my ballgame, we wouldn't permit users to take laptops home and
connect with no firewall to a DSL/cable line. That along with a few other
policies or lack thereof.





"Al Dunbar [MS-MVP]" wrote:

Quote:

"stev379" <stev379@discussions.microsoft.com> wrote in message
news:5D5EF6F8-23DC-4AA3-A56B-C04DA192F661@microsoft.com...
This is pointing me in the correct direction.
My users tend to invite a lot (very very much) of spyware. I'm finding
new
things everyday that most spyware/adware removal tools don't cover. I'd
like
to build this portion of the script to go through an array of files, and
delete them, such that I can easily add to the list without having to edit
large portions of a script for each file.

Ok, so if you want to delete the files, are you sure that that will fix the
problem? Perhaps the contents have already been installed, and the file is
only an artifact.

A few things to think about:

- what O/S's run on your clients? If w2k XP and up, then I would recommend
that, instead of running this code at each individual workstation that you
run it from an admin workstation. There are a number of ways that this could
be done...

- are you expecting to remain current by adding to your "bad-file" list only
what you run across and personally verify as malware? I would recommend
investigating various packages that can do this a little more automatically
for you.

- are you expecting to safely continue to detect bad files simply by the
filenames they arrive in?

Due to my organizations policies, politics and language barriers, training
the users to not drag their feet as they browse the web is not a viable
option.

Agreed. But even in the simplest of environments, relying on user training
as the primary defence against adware is foolhardy.

I enjoy building such scripts in my free time and figure I can learn along
the way.

There is no way you can script without learning something. I would only warn
you that you need to put more emphasis on the task of protecting your
infrastructure than on the importance of being the one to save the day with
scripting.

/Al


Thanks again for any more help you can offer.

"Al Dunbar [MS-MVP]" wrote:


"stev379" <stev379@discussions.microsoft.com> wrote in message
news:B393ED58-6E39-4022-9C9C-B88DE08A97F5@microsoft.com...
I'm building a script to find and log specific file names on a PC.

According to what you write below, you are not looking for specific
filenames so much as specific files, as you are looking only in the root
folder. Perhaps if you gave some details about what it is you want to do
when you find these files in existence, there might be a way to get
closer
to your intended result than to just provide a list of which files exist
and
which don't.

The way I
would do it now is just to rewrite the logging portion. I think there
is
a
way to loop and have it count through so it uses a different file name
each
time.How can I set it so it will go through iterations by the file
names?
So if the filenames were "filename1, filename2, filename3 etc.", it
may
use
somethinglike
filename0 (0)
filename1(1)
filename2(2)

Method 1:

filenames = array( _
"lions.txt", _
"tigers.txt", _
"bears.txt", _
"Oh my!.txt" _
)

for each filename in filenames
' your code goes here
next

Method 2:

call filecheck("lions.txt")
call filecheck("tigers.txt")
call filecheck("bears.txt")
call filecheck("Oh my!.txt")
wscript.quit

sub filecheck(filename)
' your code goes here
end sub

'My current example with just rewritting the script over an over:
LogFile = "C:\Testing.txt"
Set f = objFSO.OpenTextFile(LogFile, ForAppending, True)
If objFSO.FileExists("C:\filename0.exe")=True Then
f.WriteLine Now & ";" & WshNetwork.ComputerName & ";" & "Success" &
";" &
Err.Description
Else
f.WriteLine Now & ";" & WshNetwork.ComputerName & ";" & "Failure" &
";" &
Err.Description
Err.Clear
End If

If objFSO.FileExists("C:\filename1.exe")=True Then
f.WriteLine Now & ";" & WshNetwork.ComputerName & ";" & "Success" &
";" &
Err.Description
Else
f.WriteLine Now & ";" & WshNetwork.ComputerName & ";" & "Failure" &
";" &
Err.Description
Err.Clear
End If

'End script

Thanks for any help or suggestions!
-Steve





Back to top
Al Dunbar [MS-MVP]
Guest





Posted: Thu Dec 30, 2004 1:43 am    Post subject: Re: Iterations Reply with quote

"stev379" <stev379@discussions.microsoft.com> wrote in message
news:311450F7-801B-428B-8748-49378FE29AF4@microsoft.com...
Quote:
Agreed to all.
Understanding the manner in which this particular task can work, will help
me build the other scripts I'm tying in with this project.
Stopping processes
Deleting reg values
unregistering dll's
Deleting reg keys
Deleting temp files
Correcting any system config changes
logging
And anything more that may be needed.

In that case I would tend to try to build your tools with some consistent
overall architecture and operator interface in mind. I am currently in the
process of doing the same at work where I still, unfortunately, rely on some
adhoc, standalone scripts that are located here and there. They are too
valuable to scrap, and because they are a mixture of vbscript and batch, and
written in wildly varying styles, they are also difficult to incorporate in
a more unified toolbox - but I know I need to do that.

I'd also recommend against trying to run all of these functions from the
logonscript. The logonscript runs under the user's credentials, and they
should not have the elevated privs that some of these functions require.
Remotely managing them through a standard such as WMI will also tend to
avoid configuration problems that might cause some workstations to choke on
some of your code. It is also easier to test and debug code that runs on a
well-controlled administrative workstation than that which will run when you
are nowhere near to see what is going wrong.

Quote:
95% of the OS's on the machines with issues are 2k and XP

That's great, as you should be able to manage them remotely (although the 2k
systems might need some addons). If you need to continue to support 9x
systems, however, I would advise that you consider a different approach for
those systems. If you have to dumb all of your scripting down to what can
work on the few that are non-NT, you will be doing a disservice to the vast
majority of systems that could be better managed.

disclaimer: having read on, I see some of my comments above have assumed
that you had more administrative access than you appear to. I leave the
above unchanged, however, because it is impractical for you to continue
fixing systemic problems with local policies and procedures being what they
are (i.e. non-existent).

Quote:


I plan to stay as current as needed. We run a report about 1 per month
that
lists known issues found on infected machines. We don't have, and they
won't purchase every spyware/adware removal program that is available.

I'd advise against purchasing too many, just pick a few of the best of breed
types.

Quote:
It's
getting so that is what one needs to do in order to completely clean a
badly
infected machine.

That is one reason why it is better to work at preventing this from
happening.

Quote:
It gets time consuming manually removing them. This all
being said, I do and will continue to use various spyware programs that we
do
have (Spybot, Adaware, cwshredder, HiJack This...etc.)

Unfortunately the way the organization I work for is structured, I'm
currently only able to cover issues from my level (at the user's local
workstation, which is not what the job description was...).

Sounds an unfortunate situation...

Quote:
Until I'm able
to correct this..., I'd like to enjoy my time and give my mind something
to
do when I'm sitting at my own desk.

I really don't care much about "being the one to save the day".

Perhaps you could make a case for getting the administrative access you feel
is supposed to be part of your job if you can document the problems that
have arisen, the user time lost, your time used in fixing things, and some
alternate strategies that are more proactive than your current arrangement
allows. Good luck with that.

Quote:
My
organization is large enough that this won't matter to anyone but me.
This
is just to make my time more pleasant and productive when I go on these
calls
and help me learn more about scripting.

IMHO, your organization is lucky to have someone like you around.
Unfortunately, they are likely unaware of the value of your interest in the
wellbeing of their infrastructure, and what might happen when you eventually
leave for more rewarding work elsewhere when you get tired of this.

Quote:
Were this my ballgame, we wouldn't permit users to take laptops home and
connect with no firewall to a DSL/cable line. That along with a few other
policies or lack thereof.

There is another area (technical security policies) where you should do some
study and try to make a case for the importance of keeping your
infrastructure operational. You seem to be thinking in the right directions.

All the best of luck to you (and your organization).


/Al

Quote:





"Al Dunbar [MS-MVP]" wrote:


"stev379" <stev379@discussions.microsoft.com> wrote in message
news:5D5EF6F8-23DC-4AA3-A56B-C04DA192F661@microsoft.com...
This is pointing me in the correct direction.
My users tend to invite a lot (very very much) of spyware. I'm
finding
new
things everyday that most spyware/adware removal tools don't cover.
I'd
like
to build this portion of the script to go through an array of files,
and
delete them, such that I can easily add to the list without having to
edit
large portions of a script for each file.

Ok, so if you want to delete the files, are you sure that that will fix
the
problem? Perhaps the contents have already been installed, and the file
is
only an artifact.

A few things to think about:

- what O/S's run on your clients? If w2k XP and up, then I would
recommend
that, instead of running this code at each individual workstation that
you
run it from an admin workstation. There are a number of ways that this
could
be done...

- are you expecting to remain current by adding to your "bad-file" list
only
what you run across and personally verify as malware? I would recommend
investigating various packages that can do this a little more
automatically
for you.

- are you expecting to safely continue to detect bad files simply by the
filenames they arrive in?

Due to my organizations policies, politics and language barriers,
training
the users to not drag their feet as they browse the web is not a
viable
option.

Agreed. But even in the simplest of environments, relying on user
training
as the primary defence against adware is foolhardy.

I enjoy building such scripts in my free time and figure I can learn
along
the way.

There is no way you can script without learning something. I would only
warn
you that you need to put more emphasis on the task of protecting your
infrastructure than on the importance of being the one to save the day
with
scripting.

/Al


Thanks again for any more help you can offer.

"Al Dunbar [MS-MVP]" wrote:


"stev379" <stev379@discussions.microsoft.com> wrote in message
news:B393ED58-6E39-4022-9C9C-B88DE08A97F5@microsoft.com...
I'm building a script to find and log specific file names on a PC.

According to what you write below, you are not looking for specific
filenames so much as specific files, as you are looking only in the
root
folder. Perhaps if you gave some details about what it is you want
to do
when you find these files in existence, there might be a way to get
closer
to your intended result than to just provide a list of which files
exist
and
which don't.

The way I
would do it now is just to rewrite the logging portion. I think
there
is
a
way to loop and have it count through so it uses a different file
name
each
time.How can I set it so it will go through iterations by the file
names?
So if the filenames were "filename1, filename2, filename3 etc.",
it
may
use
somethinglike
filename0 (0)
filename1(1)
filename2(2)

Method 1:

filenames = array( _
"lions.txt", _
"tigers.txt", _
"bears.txt", _
"Oh my!.txt" _
)

for each filename in filenames
' your code goes here
next

Method 2:

call filecheck("lions.txt")
call filecheck("tigers.txt")
call filecheck("bears.txt")
call filecheck("Oh my!.txt")
wscript.quit

sub filecheck(filename)
' your code goes here
end sub

'My current example with just rewritting the script over an over:
LogFile = "C:\Testing.txt"
Set f = objFSO.OpenTextFile(LogFile, ForAppending, True)
If objFSO.FileExists("C:\filename0.exe")=True Then
f.WriteLine Now & ";" & WshNetwork.ComputerName & ";" & "Success"
&
";" &
Err.Description
Else
f.WriteLine Now & ";" & WshNetwork.ComputerName & ";" & "Failure"
&
";" &
Err.Description
Err.Clear
End If

If objFSO.FileExists("C:\filename1.exe")=True Then
f.WriteLine Now & ";" & WshNetwork.ComputerName & ";" & "Success"
&
";" &
Err.Description
Else
f.WriteLine Now & ";" & WshNetwork.ComputerName & ";" & "Failure"
&
";" &
Err.Description
Err.Clear
End If

'End script

Thanks for any help or suggestions!
-Steve





Back to top
stev379
Guest





Posted: Thu Dec 30, 2004 11:51 pm    Post subject: Re: Iterations Reply with quote

Thanks Al!!

I did in fact make my case about my admin rights and my input on policies,
just yesterday and it appears that ball is now rolling. We'll see how that
goes. It is for the reasons you stated that I left my last job... and they
now want me back.

Anyway, thanks again for your advice!


"Al Dunbar [MS-MVP]" wrote:

Quote:

"stev379" <stev379@discussions.microsoft.com> wrote in message
news:311450F7-801B-428B-8748-49378FE29AF4@microsoft.com...
Agreed to all.
Understanding the manner in which this particular task can work, will help
me build the other scripts I'm tying in with this project.
Stopping processes
Deleting reg values
unregistering dll's
Deleting reg keys
Deleting temp files
Correcting any system config changes
logging
And anything more that may be needed.

In that case I would tend to try to build your tools with some consistent
overall architecture and operator interface in mind. I am currently in the
process of doing the same at work where I still, unfortunately, rely on some
adhoc, standalone scripts that are located here and there. They are too
valuable to scrap, and because they are a mixture of vbscript and batch, and
written in wildly varying styles, they are also difficult to incorporate in
a more unified toolbox - but I know I need to do that.

I'd also recommend against trying to run all of these functions from the
logonscript. The logonscript runs under the user's credentials, and they
should not have the elevated privs that some of these functions require.
Remotely managing them through a standard such as WMI will also tend to
avoid configuration problems that might cause some workstations to choke on
some of your code. It is also easier to test and debug code that runs on a
well-controlled administrative workstation than that which will run when you
are nowhere near to see what is going wrong.

95% of the OS's on the machines with issues are 2k and XP

That's great, as you should be able to manage them remotely (although the 2k
systems might need some addons). If you need to continue to support 9x
systems, however, I would advise that you consider a different approach for
those systems. If you have to dumb all of your scripting down to what can
work on the few that are non-NT, you will be doing a disservice to the vast
majority of systems that could be better managed.

disclaimer: having read on, I see some of my comments above have assumed
that you had more administrative access than you appear to. I leave the
above unchanged, however, because it is impractical for you to continue
fixing systemic problems with local policies and procedures being what they
are (i.e. non-existent).



I plan to stay as current as needed. We run a report about 1 per month
that
lists known issues found on infected machines. We don't have, and they
won't purchase every spyware/adware removal program that is available.

I'd advise against purchasing too many, just pick a few of the best of breed
types.

It's
getting so that is what one needs to do in order to completely clean a
badly
infected machine.

That is one reason why it is better to work at preventing this from
happening.

It gets time consuming manually removing them. This all
being said, I do and will continue to use various spyware programs that we
do
have (Spybot, Adaware, cwshredder, HiJack This...etc.)

Unfortunately the way the organization I work for is structured, I'm
currently only able to cover issues from my level (at the user's local
workstation, which is not what the job description was...).

Sounds an unfortunate situation...

Until I'm able
to correct this..., I'd like to enjoy my time and give my mind something
to
do when I'm sitting at my own desk.

I really don't care much about "being the one to save the day".

Perhaps you could make a case for getting the administrative access you feel
is supposed to be part of your job if you can document the problems that
have arisen, the user time lost, your time used in fixing things, and some
alternate strategies that are more proactive than your current arrangement
allows. Good luck with that.

My
organization is large enough that this won't matter to anyone but me.
This
is just to make my time more pleasant and productive when I go on these
calls
and help me learn more about scripting.

IMHO, your organization is lucky to have someone like you around.
Unfortunately, they are likely unaware of the value of your interest in the
wellbeing of their infrastructure, and what might happen when you eventually
leave for more rewarding work elsewhere when you get tired of this.

Were this my ballgame, we wouldn't permit users to take laptops home and
connect with no firewall to a DSL/cable line. That along with a few other
policies or lack thereof.

There is another area (technical security policies) where you should do some
study and try to make a case for the importance of keeping your
infrastructure operational. You seem to be thinking in the right directions.

All the best of luck to you (and your organization).


/Al






"Al Dunbar [MS-MVP]" wrote:


"stev379" <stev379@discussions.microsoft.com> wrote in message
news:5D5EF6F8-23DC-4AA3-A56B-C04DA192F661@microsoft.com...
This is pointing me in the correct direction.
My users tend to invite a lot (very very much) of spyware. I'm
finding
new
things everyday that most spyware/adware removal tools don't cover.
I'd
like
to build this portion of the script to go through an array of files,
and
delete them, such that I can easily add to the list without having to
edit
large portions of a script for each file.

Ok, so if you want to delete the files, are you sure that that will fix
the
problem? Perhaps the contents have already been installed, and the file
is
only an artifact.

A few things to think about:

- what O/S's run on your clients? If w2k XP and up, then I would
recommend
that, instead of running this code at each individual workstation that
you
run it from an admin workstation. There are a number of ways that this
could
be done...

- are you expecting to remain current by adding to your "bad-file" list
only
what you run across and personally verify as malware? I would recommend
investigating various packages that can do this a little more
automatically
for you.

- are you expecting to safely continue to detect bad files simply by the
filenames they arrive in?

Due to my organizations policies, politics and language barriers,
training
the users to not drag their feet as they browse the web is not a
viable
option.

Agreed. But even in the simplest of environments, relying on user
training
as the primary defence against adware is foolhardy.

I enjoy building such scripts in my free time and figure I can learn
along
the way.

There is no way you can script without learning something. I would only
warn
you that you need to put more emphasis on the task of protecting your
infrastructure than on the importance of being the one to save the day
with
scripting.

/Al


Thanks again for any more help you can offer.

"Al Dunbar [MS-MVP]" wrote:


"stev379" <stev379@discussions.microsoft.com> wrote in message
news:B393ED58-6E39-4022-9C9C-B88DE08A97F5@microsoft.com...
I'm building a script to find and log specific file names on a PC.

According to what you write below, you are not looking for specific
filenames so much as specific files, as you are looking only in the
root
folder. Perhaps if you gave some details about what it is you want
to do
when you find these files in existence, there might be a way to get
closer
to your intended result than to just provide a list of which files
exist
and
which don't.

The way I
would do it now is just to rewrite the logging portion. I think
there
is
a
way to loop and have it count through so it uses a different file
name
each
time.How can I set it so it will go through iterations by the file
names?
So if the filenames were "filename1, filename2, filename3 etc.",
it
may
use
somethinglike
filename0 (0)
filename1(1)
filename2(2)

Method 1:

filenames = array( _
"lions.txt", _
"tigers.txt", _
"bears.txt", _
"Oh my!.txt" _
)

for each filename in filenames
' your code goes here
next

Method 2:

call filecheck("lions.txt")
call filecheck("tigers.txt")
call filecheck("bears.txt")
call filecheck("Oh my!.txt")
wscript.quit

sub filecheck(filename)
' your code goes here
end sub

'My current example with just rewritting the script over an over:
LogFile = "C:\Testing.txt"
Set f = objFSO.OpenTextFile(LogFile, ForAppending, True)
If objFSO.FileExists("C:\filename0.exe")=True Then
f.WriteLine Now & ";" & WshNetwork.ComputerName & ";" & "Success"
&
";" &
Err.Description
Else
f.WriteLine Now & ";" & WshNetwork.ComputerName & ";" & "Failure"
&
";" &
Err.Description
Err.Clear
End If

If objFSO.FileExists("C:\filename1.exe")=True Then
f.WriteLine Now & ";" & WshNetwork.ComputerName & ";" & "Success"
&
";" &
Err.Description
Else
f.WriteLine Now & ";" & WshNetwork.ComputerName & ";" & "Failure"
&
";" &
Err.Description
Err.Clear
End If

'End script

Thanks for any help or suggestions!
-Steve








Back to top
Al Dunbar [MS-MVP]
Guest





Posted: Fri Dec 31, 2004 12:45 am    Post subject: Re: Iterations Reply with quote

"stev379" <stev379@discussions.microsoft.com> wrote in message
news:A0565487-BEEA-4D61-8CA1-6461C921BE19@microsoft.com...
Quote:
Thanks Al!!

I did in fact make my case about my admin rights and my input on policies,
just yesterday and it appears that ball is now rolling. We'll see how
that
goes.

Great - I hope this works out well all around.

As for policy development, it can be tricky. Policy is the dominion of the
executive or upper management, not technologists. It requires a healthy
symbiosys for the two sectors to work together to develop a set of policies
in technical areas that properly reflect the needs of the organization. And,
once in place, the policies will do no good if they are not enforced by a
management that understands the effect on the bottom line, even if they do
not understand the technology and its effects all that well.

Quote:
It is for the reasons you stated that I left my last job... and they
now want me back.

You haven't given enough background for us to know whether a move back would
be a good thing, but it never hurts to have an offer in your back pocket
when discussing your concerns about the job situation with your current
boss.

Quote:
Anyway, thanks again for your advice!

I am glad that you found it useful, and hope you get some more advice here
as you need it.


/Al

Quote:


"Al Dunbar [MS-MVP]" wrote:


"stev379" <stev379@discussions.microsoft.com> wrote in message
news:311450F7-801B-428B-8748-49378FE29AF4@microsoft.com...
Agreed to all.
Understanding the manner in which this particular task can work, will
help
me build the other scripts I'm tying in with this project.
Stopping processes
Deleting reg values
unregistering dll's
Deleting reg keys
Deleting temp files
Correcting any system config changes
logging
And anything more that may be needed.

In that case I would tend to try to build your tools with some
consistent
overall architecture and operator interface in mind. I am currently in
the
process of doing the same at work where I still, unfortunately, rely on
some
adhoc, standalone scripts that are located here and there. They are too
valuable to scrap, and because they are a mixture of vbscript and batch,
and
written in wildly varying styles, they are also difficult to incorporate
in
a more unified toolbox - but I know I need to do that.

I'd also recommend against trying to run all of these functions from the
logonscript. The logonscript runs under the user's credentials, and they
should not have the elevated privs that some of these functions require.
Remotely managing them through a standard such as WMI will also tend to
avoid configuration problems that might cause some workstations to choke
on
some of your code. It is also easier to test and debug code that runs on
a
well-controlled administrative workstation than that which will run when
you
are nowhere near to see what is going wrong.

95% of the OS's on the machines with issues are 2k and XP

That's great, as you should be able to manage them remotely (although
the 2k
systems might need some addons). If you need to continue to support 9x
systems, however, I would advise that you consider a different approach
for
those systems. If you have to dumb all of your scripting down to what
can
work on the few that are non-NT, you will be doing a disservice to the
vast
majority of systems that could be better managed.

disclaimer: having read on, I see some of my comments above have assumed
that you had more administrative access than you appear to. I leave the
above unchanged, however, because it is impractical for you to continue
fixing systemic problems with local policies and procedures being what
they
are (i.e. non-existent).



I plan to stay as current as needed. We run a report about 1 per
month
that
lists known issues found on infected machines. We don't have, and
they
won't purchase every spyware/adware removal program that is available.

I'd advise against purchasing too many, just pick a few of the best of
breed
types.

It's
getting so that is what one needs to do in order to completely clean a
badly
infected machine.

That is one reason why it is better to work at preventing this from
happening.

It gets time consuming manually removing them. This all
being said, I do and will continue to use various spyware programs
that we
do
have (Spybot, Adaware, cwshredder, HiJack This...etc.)

Unfortunately the way the organization I work for is structured, I'm
currently only able to cover issues from my level (at the user's local
workstation, which is not what the job description was...).

Sounds an unfortunate situation...

Until I'm able
to correct this..., I'd like to enjoy my time and give my mind
something
to
do when I'm sitting at my own desk.

I really don't care much about "being the one to save the day".

Perhaps you could make a case for getting the administrative access you
feel
is supposed to be part of your job if you can document the problems that
have arisen, the user time lost, your time used in fixing things, and
some
alternate strategies that are more proactive than your current
arrangement
allows. Good luck with that.

My
organization is large enough that this won't matter to anyone but me.
This
is just to make my time more pleasant and productive when I go on
these
calls
and help me learn more about scripting.

IMHO, your organization is lucky to have someone like you around.
Unfortunately, they are likely unaware of the value of your interest in
the
wellbeing of their infrastructure, and what might happen when you
eventually
leave for more rewarding work elsewhere when you get tired of this.

Were this my ballgame, we wouldn't permit users to take laptops home
and
connect with no firewall to a DSL/cable line. That along with a few
other
policies or lack thereof.

There is another area (technical security policies) where you should do
some
study and try to make a case for the importance of keeping your
infrastructure operational. You seem to be thinking in the right
directions.

All the best of luck to you (and your organization).


/Al






"Al Dunbar [MS-MVP]" wrote:


"stev379" <stev379@discussions.microsoft.com> wrote in message
news:5D5EF6F8-23DC-4AA3-A56B-C04DA192F661@microsoft.com...
This is pointing me in the correct direction.
My users tend to invite a lot (very very much) of spyware. I'm
finding
new
things everyday that most spyware/adware removal tools don't
cover.
I'd
like
to build this portion of the script to go through an array of
files,
and
delete them, such that I can easily add to the list without having
to
edit
large portions of a script for each file.

Ok, so if you want to delete the files, are you sure that that will
fix
the
problem? Perhaps the contents have already been installed, and the
file
is
only an artifact.

A few things to think about:

- what O/S's run on your clients? If w2k XP and up, then I would
recommend
that, instead of running this code at each individual workstation
that
you
run it from an admin workstation. There are a number of ways that
this
could
be done...

- are you expecting to remain current by adding to your "bad-file"
list
only
what you run across and personally verify as malware? I would
recommend
investigating various packages that can do this a little more
automatically
for you.

- are you expecting to safely continue to detect bad files simply by
the
filenames they arrive in?

Due to my organizations policies, politics and language barriers,
training
the users to not drag their feet as they browse the web is not a
viable
option.

Agreed. But even in the simplest of environments, relying on user
training
as the primary defence against adware is foolhardy.

I enjoy building such scripts in my free time and figure I can
learn
along
the way.

There is no way you can script without learning something. I would
only
warn
you that you need to put more emphasis on the task of protecting
your
infrastructure than on the importance of being the one to save the
day
with
scripting.

/Al


Thanks again for any more help you can offer.

"Al Dunbar [MS-MVP]" wrote:


"stev379" <stev379@discussions.microsoft.com> wrote in message
news:B393ED58-6E39-4022-9C9C-B88DE08A97F5@microsoft.com...
I'm building a script to find and log specific file names on a
PC.

According to what you write below, you are not looking for
specific
filenames so much as specific files, as you are looking only in
the
root
folder. Perhaps if you gave some details about what it is you
want
to do
when you find these files in existence, there might be a way to
get
closer
to your intended result than to just provide a list of which
files
exist
and
which don't.

The way I
would do it now is just to rewrite the logging portion. I
think
there
is
a
way to loop and have it count through so it uses a different
file
name
each
time.How can I set it so it will go through iterations by the
file
names?
So if the filenames were "filename1, filename2, filename3
etc.",
it
may
use
somethinglike
filename0 (0)
filename1(1)
filename2(2)

Method 1:

filenames = array( _
"lions.txt", _
"tigers.txt", _
"bears.txt", _
"Oh my!.txt" _
)

for each filename in filenames
' your code goes here
next

Method 2:

call filecheck("lions.txt")
call filecheck("tigers.txt")
call filecheck("bears.txt")
call filecheck("Oh my!.txt")
wscript.quit

sub filecheck(filename)
' your code goes here
end sub

'My current example with just rewritting the script over an
over:
LogFile = "C:\Testing.txt"
Set f = objFSO.OpenTextFile(LogFile, ForAppending, True)
If objFSO.FileExists("C:\filename0.exe")=True Then
f.WriteLine Now & ";" & WshNetwork.ComputerName & ";" &
"Success"
&
";" &
Err.Description
Else
f.WriteLine Now & ";" & WshNetwork.ComputerName & ";" &
"Failure"
&
";" &
Err.Description
Err.Clear
End If

If objFSO.FileExists("C:\filename1.exe")=True Then
f.WriteLine Now & ";" & WshNetwork.ComputerName & ";" &
"Success"
&
";" &
Err.Description
Else
f.WriteLine Now & ";" & WshNetwork.ComputerName & ";" &
"Failure"
&
";" &
Err.Description
Err.Clear
End If

'End script

Thanks for any help or suggestions!
-Steve








Back to top
 
Post new topic   Reply to topic    Windows Server Forum Index -> Programming All times are GMT
Page 1 of 1

 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum




New Topics Powered by phpBB