I upgraded to a (hand me down) Dell Latitude E6530 not long ago. I loaded it with Windows 8.1 (and Classic Shell, because one must). I kept having wireless trouble – dropping off of networks. It wasn’t isolated to my home. What I believe I’ve determined is that, in a nutshell, Windows handling of N networks kind of sucks. I disabled N and since then have been rock solid.
Navigate to your network adapters, right click on the wireless and choose Properties. Beneath the adapter description choose Configure:
Choose the Advanced tab, then locate 802.11n Mode. Switch the Value to Disabled and OK your way out of all.
I had installed and configured a trial of a web analytics package for my day job and had the server put through the wringer. Among the issues found was a redirect buried deep in the code to cornify.com, “…the #1 unicorn and rainbow service worldwide, spreading sparkly happiness around the world.” I added it to my list of concerns for the products developers and shipped it to them. They responded that the cornify link was an “Easter Egg” put there by one of the coders and wasn’t a security concern.
My immediate thought was this: What if cornify becomes something else? What if it stops being the #1 unicorn and rainbow service worldwide? What if someone buys the name, or hijacks it, and it instead leads to an unsavory site? How will you explain to your paying customers that you’re rushing out an update to the web app they’ve paid you handsomely for, and that their administrators need to burn their time updating it ASAP, because a redirect you added on a whim now points to something lawsuit inducing? Less dramatically, and more likely, why would you want to deal with that inevitable customer who gave you thousands of dollars for your product and doesn’t have a sense of humor? The one who thinks it’s completely unprofessional and a poor reflection on them that your product did what you think is a lighthearted redirect? Is being clever (and let’s be fair – it’s not all that clever) worth that risk?
And that’s when I realized I’d stopped being the Young IT Guy and I’d become the Old IT Guy.
I use Avaya One-X for work. I got the above error this morning. I couldn’t find a resolution via Googling, and Avaya’s support is notoriously sucky. BUT, I did find out what the purpose of Preferences.xml is. It keeps settings like window positions. Bearing that in mind, I figured before reinstalling I’d try blowing it away (renaming it, actually) to see if it would recreate. It did, and the app came up fine.
New hard drives have arrived for my workstation and laptop. They’re desperately overdue for a rebuild. I love rebuilding and I hate it. I love it because newly built machines run so smoothly, so cleanly, and have that new-machine smell. It’s like virtual spring-cleaning.
I hate rebuilding because there’s so much stuff on my machines. I’ve done a better job over the years of compartmentalizing (and even backing up) my data, but there’s still a lot of it – more than I’d like. And the applications. I use so many applications! Every rebuild I think “I don’t need 3/4 of these apps. I’m not putting them back on.” But eventually, inevitably, as I work on this and that my installed app list grows, and I find myself installing a significant amount of the apps I insisted I wouldn’t. Such is the curse of the breadth of things I work on, I suppose. Just this morning a coworker from a completely different department commented that I’m the bitch for my department. I work on whatever needs working on. My boss generously calls me his “tool belt.” Bitch is, honestly, more accurate.
Anyway, here are a few things that make my rebuild process less arduous.
I always build fresh onto new drives, holding onto the old ones. Drives are cheap. There’s nothing worse than blowing your drive away, rebuilding, and suddenly remembering something of Significant Importance™ that you forgot to back up. Don’t sweat that. Take the time to decrypt your current drives (you do encrypt them, don’t you) and set them aside. Build on a new drive, and keep your old ones around for a few weeks just to be sure. Then you can wipe them and use them as scratch drives or external storage or replacement drives for that friend whose drive craps out or whatever.
Make a list of your installed applications. It’s easy:
Open a command prompt with elevated rights (Start > Run > type in CMD. When the CMD icon appears, right click and Run as Administrator).
Type in WMIC.
Type in /output:c:\path\to\installed_list.txt product get name,version where path\to is, well, the path to wherever you want to write your installed_list.txt.
I was writing a script that would scan remote Windows systems and return their installed software, complete with version information (a requirement), and quickly discovered that the process was more arduous than I had originally anticipated. How to pull it? WMI? Use PowerShell? Glean the information from the registry? I fiddled with each and, given that I was working with a broad array of OS levels and a mix of 32 and 64 bit, each option had its annoying pitfalls.
Sometimes it’s better to let someone else do the work. This is one of those times.
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.