So, it is the final quarter of the year, internal audit has just woken up from their hibernation directly up your…sleeves, and wants to keep stuff compliant.
Your manager, for the little sadist that he is, sends you a list of some twenty+ applications to uninstall from all the end-user machines.
As you already experienced the pain of uninstalling different applications from different vendors before, you know that not every company builds a way to perform silent/command line uninstallation.
So you tell your manager: Not this time you neo-fascist! (In your mind, of course, you don’t want to end up on the streets working for Facebook, because #DeleteFacebook right? Too much? ok…)
Today we will use a commercial uninstall tool coupled with our custom script to uninstall virtually any software, remotely and silently.
First, you need to buy Revo Uninstaller Pro Portable, it costs around 30$ per year, cheaper than a mid-fancy dinner.
Then, you create a deployment package, save my following script in the same directory as RevoUnPro.exe and publish it to all your users:
Internet, we meet again!
No, it didn’t take me 14 months to write this article, i just had a bad case of fleas that took a while to shake off (metaphorically, of course).
As you already know, Windows server 2012R2 is already being shipped with the new PowerShell feature/framework: Desired State Configuration. In this article i will list a summary of key differences between group policy and DSC, in ENGLISH.
Microsoft provided us several tools to manage Windows, other than GP and DSC (e.g. SCCM DCM, InTune), but I wanted to compare those two specifically because they are free, mainly.
Enough chit-chat, differences, in no particular order:
- DSC, by using MOF files (which are not proprietary to Windows), can manage Linux boxes, while group policy (currently) can’t.
- DSC can use any MOF file created by any future 3rd party product that can potentially leverage DSC as a policy engine.
- DSC is easy to extend (the only limit is PowerShell’s potency), whereas extending Group Policy can be really daunting.
- DSC writes all errors in the Windows event logs when things go south, while not all Group Policy settings does that.
- DSC periodic configuration refresh checks for updates every 15 mins by default, whereas Group Policy’s background refresh can take up to 120 mins.
- DSC stores the required config and resources locally, so even if there is no network connection, configuration refresh WILL occur, whereas group policy requires connections to AD and SYSVOL to perform its background refresh.
- DSC config/policy can be applied to workgroup machines, thus your DMZ machines will never be out of shape again, whereas group policy requires the machine to be in an AD domain.
- DSC, while declarative, does not have any GUI (yet), while group policies GUI is easy to use and well known.
- DSC is more complex to apply, whereas Group Policy is click-driven.
- DSC provides centralized triggering of configuration distribution, while Group Policy relies on the GP client to trigger refreshes.
- Group Policy uses a combination of event-driven (like computer startup and user logon) mechanisms, while DSC does not have anything like it yet.
- DSC tattooes its changes on the machine, that means when a DSC config item is no longer applied, its changes does not revert back to its original state, whereas “most” Group Policy settings are not tattooed (GPP is another story).
- DSC scripts is more human-readable than a raw Group Policy file.
- In my opinion, DSC is more likely to be used on Servers, while Group Policy is still for both servers and clients (excluding perimeter machines).
That’s it, short and simple, I hope you’ve found it useful. Let me know what do you think by leaving a comment below.
Until next year (hopefully not), have a great one!
There are tons of remote support tools for AD environments, but most of them are commercial, and some of them are user initiated (like Lync 2010+ desktop sharing feature), today we will implement an agentless (sort of), free and pretty effective solution, the end result is a box that you enter the destined Username in (the person you’re trying to help), et voila, you have control over his screen ! (gentlemen, after his permission, of course)
Chapter I :
The base application that we will use is “Windows Remote Assistance” which ships for free with most Windows 7 flavors, the rest is scripting gimmicks.
Out of the box, Windows remote assistance will work if the requester sent an invitation file to the helper, but in our case, we want to initiate the process by offering our help before we even hear the nagging.
To do so, we need to create and link a GPO to our computers OU that enables just that :
Computer Configuration > Policies > Administrative Templates > System > Remote Assistance
Enable the “Offer Remote Assistance” option and select who can offer remote support, typically you will add your Help Desk group
After you gpupdate the end-user’s machine, try it:
Open “Windows Remote Assistance” from your helper workstation, then click on Continue reading
In some cases you may feel an urge to experience a lucid nightmare intentionally: to Generate a Blue Screen of Death !
Why ? You may have some sort of cluster configuration or some kind of HA solution that you want to dirty-test
This can be done using several ways, one including editing the registry and using the NumLock key, but the one we’ll check today is much simpler
First you need to have PowerShell installed (you can produce the same outcome by using any tool that can interface with WMI, PowerShell is the easiest)
Then open a elevated PowerShell console and type :
Get-Process | Stop-Process
A nice BSOD will appear
If you want to produce a BSOD on a remote machine, you need to have PowerShell remoting enabled and some firewall exceptions added to the target. To do so, open an elevated command prompt console (on the remote machine) and run:
Then from your machine, issue the following:
That’s my time for today, see you in a few days (or weeks…or months)
Yes, 5 months have passed since my last post, I was busy,with uhmm, stuff…
Now enough with my hypocrisy, today my curious monkey refused to sleep before i test the new “Wan Optimization” that Microsoft allegedly added to its new RDP v8.0 feature set that ships natively with Windows 2012.
So i setup 2 client machines, one with RDP v7.1 client and another with RDP v8.0, i will be connecting to my remote machine from home via an RD gateway server which is located in our remote branch’s DMZ.
Now we have to find some material worth testing on, and what is more frustrating than playing flash games over RDP? Their rich graphics, high frame rates and fade in-out effects (alpha) makes it the best candidate.
I decided to go with something zombies related, “Earn to die 2012” is a great game (Disclaimer above): www.flashgames247.com/play/15994.html
*Round 1: RDP client v7.1 connecting to RDP v7.1 (or v8.0)
- Of course RDP v8.0 is backward compatible so if you connect from a v7.1 client it will work but you will not get v8’s features
- General Experience: Very slow and choppy gameplay, hangs when fading effects come into play, quality is good
- Judgment: Unplayable
Wireless access in the enterprise can be a huge PITA ! Because you have to find the correct balance between usability and security, you don’t want everyone contacting the help desk asking on how to connect, and based on your hardware, it can be tricky.
In my case, we are using Trapeze wireless controllers (Trapeze recently acquired by Juniper), it has all the functions we need to create a robust wireless access scheme.
I decided to go with 3 SSID’s: Continue reading