Windows Explored

Everyday Windows Desktop Support, Advanced Troubleshooting & Other OS Tidbits

Archive for February 8th, 2013

My Work Desktop

Posted by William Diaz on February 8, 2013


Pretty tidy, I say:

SAM_1884

Five Windows workstation, and, yes (dread), that’s a Mac on the right. I don’t care for it. Yes, that’s Mr. Lebowski (the Dude) above monitor number 2. Above number 4 is the immortal Toshiro Mifune (Sanjuro).

Moving to the cubicle wall are some other immortal greats:

SAM_1886

From left to right: Christopher Walken from Balls of Fury, Christoph Waltz from Inglorious Basterds, Big Brother from 1984 (he is always watching), Sugar from No Country for Old Men (by far the best villain ever), Cpt. James T Kirk (evil Kirk episode top), Walken again (ages gracefully), Michael Fassbender, also from the Basterds, Heston and the Apes from Planet of the Apes, Richard Burton from 1984 (there are five of him), and more Samurai Mifune.

Of course, reading material:

SAM_1891

Haven’t gotten around to Windows Internals Part II yet. English Ales are the best. BJ’s is great, too. Beer!

Posted in Uncategorized | 2 Comments »

Vague Errors and No, You Can’t Be An Admin on Your Workstation

Posted by William Diaz on February 8, 2013


In real estate, its all about location, location, location. In today’s Windows workplace environment its all about security, security, security. Legacy apps present challenges because they want to do things that are not going to work in our environment. For example, this vague error when our user is trying to run an app:
image

Not a lot to go on but our helpdesk was able to get to work by running the app in an elevated state and I knew then that this app obviously wasn’t designed with security in mind. No doubt, the app was trying to modify one or more of its files that was in a location that was locked down by the secure Windows 7 file system. The user wanted to be admin to workaround it. “Sorry, but we can’t give you that kinda juice.” But we could likely change the security permissions on the file and grant Users the right to modify it … assuming that was the case. Taking a look with Process Monitor, I ran the app, set a filter for Access Denied on the file system and got the following:
image

Yep, legacy apps don’t care much for putting stuff inside C:\Windows, but this is bad practice today because standard user accounts will not have the necessary privileges to create and modify any files placed here. The workaround in this case (because the user insists they really need this app) was to change the security permissions of the files the app was trying to write to to give Users Modify permissions:

image

I wish they were all this easy.

Posted in Troubleshooting | Leave a Comment »