I set up a VisualCron job to kick off a Powershell script to reach out to certain directories – built dynamically from an array – to check for content. The script ran perfectly when invoked manually, but through VisualCron it would error out with a truncated path:
The above path should have been \\atldireng03\e$\download\. I just could not get the path to resolve. The script that builds the path looks similar to this:
Ultimately the issue was one of rights. The account VisualCron was utilizing to invoke the script did not have rights to the administrative share path being built by the script. Change the account to an administrator on the remote server and the script ran like a charm. Now, that it would error out with this weird truncated path problem rather than something referring to a lack of sufficient rights is frustrating. I suppose it’s because it could not ‘see’ the path (hence “it does not exist”), but were you to manually attempt to map to a path you hadn’t rights to pretty much all OSes would return you some kind of informative error about insufficient rights. Not here. And for the record, I haven’t tried running the script manually through a Powershell prompt without rights to the paths to see what happens. It’s entirely probable this uninformative error is on Powershell’s side and not VisualCron.
I’ve been trying in vain to organize my substantial MP3 collection. I know that in the age of streaming MP3’s are passe, but I just can’t quit ’em. I listen to a lot of music that isn’t readily available for streaming.
One of the things I’m nitpicky about is Genre tagging. I like that stuff to be correct. Thing is, sometimes I get lazy. So, I dug in to see if I could hack out a quick script to scan subdirectories in my collection and root out MP3’s with incorrect or missing Genre tags. This is a very raw little script with zero error handling. It examines the first file in every subdir, and writes to an output file every directory where that first file’s genre tag doesn’t match what it should. It requires taglib-sharp.dll.
Microsoft® Windows PowerShell Extensions for Microsoft® SQL Server® 2012 (PowerShellTools.msi)
If you get a 2503 or 2502 error while trying to install, as I did, you may not have sufficient rights. Try either killing explorer.exe and restarting it with admin privs or invoking the msi from within an elevated command prompt.
We’ve used a variety of third party tools to monitor Active Directory domain account changes. They’ve all either been expensive or kind of sucked (or, unfortunately, both). But if you’re running a relatively new OS on your controller you can use the magick of Powershell to ship you alerts on account changes! Powershell can monitor the local Security Event Log on your controller and ship you an email when events matching your description are entered. Here’s an example Powershell script:
Today at work I had a need to query a bunch of databases for a particular, er, thing, and then send that thing, if found, to myself via email. I needed this to happen every morning. I decided, since we’re talking about a MS SQL and Windows 2003/2008 environment, that Powershell was the way to go. And it was – until I popped it into scheduler.
When executed as a scheduled task, the email didn’t send. Things before and after the email routine worked – the arrays populated, the log file filled – but the email didn’t go. Firing it from a Powershell manually, everything went fine.
Being the stubborn arse I am, rather than get to Googling I started ripping things apart. I had the query dump its results into a temp file that a separately scheduled script would open, parse, email and then clear. Same result: run manually everything worked peachy. Scheduled, no email.
In the end the problem was irritatingly simple. For some reason, when run as a scheduled task the script didn’t keep the socket open to the SMTP server long enough for a successful transmission. I added a Start-Sleep -s 5 right after the SMTP command to give it a 5 second breather before continuing on. Voila – email success. How silly.
I think I’m going to like Powershell just fine. Other than quirks like this, and getting used to the syntax, it’s easy enough – and it seems a lot of Windows specific stuff is streamlined, at least in comparison to my old go-to admin scripting languages.