Rather than reinventing the wheel each time they create a script, scripters often adapt existing code. However, there are many situations in which you might have a script but need to adapt it to run under a specific security context. For example, suppose you need a script to monitor Windows services locally and remotely and you find a script called ServiceMonitor.wsf. This script performs the tasks you want to automate. It uses Windows Management Instrumentation (WMI) to monitor services, restart a monitored service when it stops, and send an email alert if the service doesn't restart. However, you notice that to run ServiceMonitor.wsf on remote machines, users need to enter an ID and password when they launch the script. Because this information is entered on the command line in plaintext, this practice isn't secure. In addition, because the script provides alerts by sending email messages through a specified secured SMTP relay, the security credentials to establish an SMTP connection are hard-coded in the script, which is another insecure practice. Although you could configure the SMTP relay to accept anonymous connections, doing so is undesirable because it introduces other security risks. . . .
Microsoft this week revealed that its Xbox 360 video game console outsold its Sony PlayStation 3 rival 3-to-1 on "Black Friday," which curiously describes the three day weekend after Thanksgiving, a period that unofficially kicks off the holiday selling ...
Order Your Fundamentals CD Today! Register today for your in-depth copy of one of three Fundamental CDs on the following topics – Exchange, SQL, and SharePoint.