This category contains any management related posts.
In the second year of my internship, I killed 90 computers (the only three labs in our school). By killed, I am talking full Blue Screen of Death that didn’t go away from a reboot. Each machine has to be manually reimaged. Worse, I had to reimage them with Ghost…
Isn’t the new BSOD great?
That hectic morning taught me two important things when it comes to testing. It would take a few more years for me to learn from two other common mistakes. Here are the four things that might save your job:
I was recently asked “How can I start tracking user logins without modifying Active Directory or writing to a database?” Odd question right? Our reader, let’s call him Jose, had a few issues:
To me, it seems like his boss has their priorities a little mixed up – but oh well. Before finding out these restrictions, I referred him to these two articles:
I was hoping that the powers that could modify AD in his company would see the benefits of the solutions above. It turns out that they don’t trust this site… (or Microsoft documentation for that matter).
After a few emails back and forth, I found out what was going on and we came up with a manual hack to speeding up the whole “what computer are you on?” routine that every one of us face. We ended up using an old time tool with a modern deployment method.
With one registry change plus a deployment with Group Policy Preferences, we can stick the Computer Name under the start menu. Instead of a shortcut to Computer (or My Computer), the user sees “Computer: COMPUTERNAME”. This allows you to quickly check a computer name or to easily tell an employee how to find the computer name.
Active Directory Administrator should regularly clean up stale computers from Active Directory. This is a fact. If you haven’t automated the stale computer cleanup process, take 10 minutes to read this background article and to set it up. Doing so will make your life easier. After all, cleaning up your stale computers will help you by:
When a computer is marked as stale, it can occasionally come back to life! I like to call these zombie computers. It makes my day sound more exciting…
Binnnnarrry….. (said in a creepy zombie voice)
How do these stale computers come back to life? Here is an example: a user might have a laptop off the domain for a year. This laptop would be marked as stale and disabled. When the user returns, a help desk technician might re-enable the laptop without moving it from your Stale Computers container.
Just this week, we had 9 computers that had this issue. That meant 9 computers were not being managed by Group Policy! That meant 9 computers that did not have AppLocker, UAC, or other security settings applied to them! That mean 9 computers with a craving for human brains! Fortunately for us, PowerShell can fix two out of these three problems automatically! A shotgun will fix the last one…
There is no doubt that Windows 8 relies on .NET Framework 4. But what about .NET Framework 3.5? Just on my machine, three of my daily tools require it (Advance Group Policy Management, Print Manager Plus. and VMware vSphere Client). If you try to install it from the source files, you will find that they are contained on orginial media and not preloaded on your install! Worse, installing it from Programs and Features will give you a cryptic error code. On two machines, I got two different codes – 0x800F0906 and 0x800F081F.
To get past this issue, we can use DISM or MDT. We can even automatically enable this feature in our Task Sequence to save future us some time!
The “Run in Logged on User’s Security Context” option is one of the least understood (and used) features of Group Policy Preferences. Understanding how to use it (and when) can save you hours of frustrating and fruitless troubleshooting! In this post, we will cover a practical example showing when to use “Run in Logged on User’s Security Context”. First, a little introduction on this cool little Group Policy setting:
