Archive for the 'desktop management' Category

Virtual Desktop provisioning with PowerShell

I love it when teams in my own company (Quest) get serious about PowerShell, and our VDI (virtual desktop) folks are definitely the group that is very serious about PowerShell-enabling their application. Which makes a lot of sense – if you cannot automate bulk virtual desktop management how would you get the benefit of mass centralized desktop administration?

So let me give them a plug: they have just released a great new version which among many other things fully supports virtual desktop provisioning:

And they made available a beta of the next version that adds several new capabilities amongst which is the capability to configure (or reconfigure) virtual desktops for use Microsoft Dynamic Memory and RemoteFX.

And the rumour is that there is a PowerPack in the works. If you consider virtualizing desktops in your company or starting your Desktop-as-a-Service (DaaS) business – check out vWorkspace – this team is committed to full PowerShell scriptability of the platform.

Systems Management with NetPoint and PowerGUI

Need a simple and affordable way to manage your Windows systems in batch? Shannon Ma from NetPoint has just posted a free PowerPack which integrates with NetPoint PowerShell interfaces and lets you easily inventory your network.

The PowerPack can work with both free and commercial version of NetPoint (guess, which one gives you more functionality ;)) and provides a great way to collect various information from computers on your network, as well as install/unistall software, do restarts, run commands, and so on – all in all about 30 various tasks:

Read more, leave your feedback and download the PowerPack here.

Get Computer by IP Address

Get-QADComputer can accept lots of forms of computer identification: name, DNS name, DN, and so on, but IP address is currently not there. Fear not! PowerShell and .NET can do wonders.

With a little bit of help from Jeffrey, I scripted a simple function which turns IP addresses into computer names and supports every possible scenario I could think of:

# No parameters
PS C:\> Get-ComputerNameByIP
Please supply the IP Address: 10.20.30.40
mycomp.domain.local

# With parameter
PS C:\> Get-ComputerNameByIP 10.20.30.40
mycomp.domain.local

# With pipeline
PS C:\> '10.20.30.40', '10.20.30.41' | Get-ComputerNameByIP
mycomp.domain.local
myserv.domain.local

# Or reading from a text file (one IP address per line)
PS C:\> get-content C:\temp\ip_addresses.txt | Get-ComputerNameByIP
mycomp.domain.local
myserv.domain.local

# Or piping that further to get AD computer objects
PS C:\> '10.20.30.40', '10.20.30.41' | Get-ComputerNameByIP | 
               ForEach-Object { Get-QADComputer -DnsName $_ }

Name    Type      DN
----    ----      --
MYCOMP  computer  CN=MYCOMP,OU=Redmond,OU=US,OU=Desktops...
MYSERV  computer  CN=MYSERV,OU=Redmond,OU=US,OU=Servers,...

And here’s the actual function which you can copy/paste into your PowerShell window, add to your PowerShell profile, or “dot-source” from an external file.

function Get-ComputerNameByIP {
    param(
        $IPAddress = $null
    )
    BEGIN {
    }
    PROCESS {
        if ($IPAddress -and $_) {
            throw 'Please use either pipeline or input parameter'
            break
        } elseif ($IPAddress) {
            ([System.Net.Dns]::GetHostbyAddress($IPAddress)).HostName
        } elseif ($_) {
            [System.Net.Dns]::GetHostbyAddress($_).HostName
        } else {
            $IPAddress = Read-Host "Please supply the IP Address"
            [System.Net.Dns]::GetHostbyAddress($IPAddress).HostName
        }
    }
    END {
    }
}

Have fun!

Tags: , , , ,

PowerShell Adoption by Platform

I have always wondered how much is PowerShell adopted across various administrative tasks. Now I finally found the stats.
Windows Server and Active Directory are far ahead, with Windows Desktop being a runner-up, Exchange on distant 3rd and everything else far behind.

PowerShell use survey statistics by application and platform

My take on the data:

  • Server and AD management tasks are far ahead of everything else. Too bad the survey didn’t distinguish between the two.
  • It is a bit surprising the desktops took number 2. My guess is that respondents just meant using PowerShell on their desktop for their personal needs. Despite existing 3rd-party solutions I doubt PowerShell v1 can be used that widely for mass desktop management. I think we will need to wait for v2 and remoting to see this taking off.
  • Not surprisingly almost a 3rd of respondents are not using PowerShell for admin tasks at all. After all, there is some learning curve involved here and PowerShell is not yet available for any platform.
  • Almost a quarter of PowerShell users employ it for Exchange 2007. A very good result! After all, Exchange 2007 was released not that long ago, and has just got its SP1.
  • In general, it looks like platforms with no cmdlets available don’t really get PowerShell fans. .NET can be used to manage SQL and SharePoint – but look how much behind are they! Exchange 2003 can actually be managed with PowerShell, but there are no native cmdlets built-in – and as result PowerShell use is just 1.5%. Compare that to 23.4% Exchange 2007 got!
  • I wonder why Operations Manager is relatively low. Less adopted than Exchange 2007? OpsMgr admins less willing to script? OpsMgr tasks not really requiring scripting and command-line use?

The survey was carried out by Quest Software and took place in the very end of December 2007 and early January 2008. It was promoted at PowerGUI.org, this blog, myITForum.com and a few other PowerShell blogs. About 200 people responded. The exact question was: “Select the systems you are currently managing with Windows PowerShell“.

Tags: , , , , , , ,

Specops Command/PowerGUI Press Release

Last month I blogged about how you can use PowerGUI and Specops Command to not only create and debug your PowerShell scripts but also to deploy them across multiple desktops in your network. Today the press release about the integration went live.

Here are the quotes from the press release:

The integration makes it possible to use the powerful and free PowerShell script editor, Quest PowerGUI, directly from Specops Command and thus provide features like IntelliSense (to access descriptions of functions) and debugging capabilities when editing PowerShell scripts.

“The incredible synergy created by integrating Specops Command and Quest PowerGUI into a single powerful solution is very exciting,” said Dmitry Sotnikov, New Product Research Manager at Quest Software. “Giving users the ability to invoke PowerGUI Script Editor to edit and debug their scripts and then use Specops Command to distribute the script to computers in the network makes perfect sense.”

“The combined power and ease of use of Specops Command and Quest PowerGUI will forever change the landscape of distributed Windows-based computer management and will make Windows PowerShell the number one solution used everywhere — not only for administering a small number of servers, but tens of thousands of computers at a time,” said Thorbjörn Sjövold, CTO of Special Operations Software. “Also, by simply using the free Quest PowerGUI with the free version of Specops Command, Logon and Startup scripts as we know them today will never be the same.”

See full text here.

Tags: , , ,

Debug in PowerGUI – deploy in Specops Command

Guys at Specops have just released an updated version of their flagship product – Specops Command – and it is integrated with PowerGUI.

Here’s how the integration works:

1. You start Specops Command and create a group policy containing a PowerShell script.

2. You click the Edit in PowerGUI button below the text box (see the screenshot below):

Specops Command PowerGUI integration

3. The script opens in PowerGUI Script editor in which you edit and debug the code.

4. Once you are happy with the code, you click Save and close the editor. The script gets automatically updated in Specops Command.

5. You target the policy to the computers in the network on which it should be run, and the script gets deployed.

I think this is an incredible better-together story, allowing you to have the best of both worlds: full-features debugging in PowerGUI editor, and then scalable deployment across the network through Specops.

Good job by both teams!

Tags: , , ,

Manage Local Users and Groups with PowerShell

We’ve been blogging so much about using PowerShell to manage AD users and groups so it’s probably the right time now to check-out PowerShell usage to do the same for local Windows (workstation or server) accounts management.

Luckily, learning that is very straight-forward.

Rob “Deuce” Doucette published a PowerPack for Local Users And Groups management with PowerShell to the PowerGUI library.

Quoting from his description:

This pack allows you to enumerate local users and groups as well as execute some actions against users. Along with the local users, you’ll be able to see the last login time, password age, and the number of bad password attempts. As well, you’ll be able to:

  • view the password/account policies for users -change a users password
  • force a user to change their password next time they login
  • add/remove users to a group
  • enable/disable users

As usual with PowerGUI, all these actions generate PowerShell code on the “PowerShell Code” tab so once you’ve done all that in UI, click the tab and copy-paste the code into your scripts or command prompt.

This should work for Windows XP, 2003, Vista and 2008 (aka Longhorn.)

To use the pack:

  1. download and install PowerGUI,
  2. download the localuserandgroups.snapin file attached to the library post, and
  3. import the file into the PowerGUI tree.

Tags: , , , , , , ,

Find where that user is

There was a question in the PowerShell newsgroup on finding on which computer is a particular user located.

Here’s my take on the one-liner finding the user and computer:

PS C:\> Get-QADComputer | foreach { Get-WmiObject -Class Win32_ComputerSystem -ComputerName $_.Name } | where { $_.UserName -eq "DOMAIN\username" } | Format-Table Name, UserName

Name                                    UserName
----                                    --------
MYCOMP                                  DOMAIN\username

Basically I am:

1. Getting the list of computers.

2. Going to each of them with a WMI query to get information on the current session on the computer.

3. Applying the where filter comparing the UserName property to the username.

4. Outputting the computername and username in a table.

This is it!

You can make it slightly complicated if you need IP address (it is not present in the Win32_ComputerSystem class) – we can get that by adding:

PS C:\> Get-QADComputer | foreach { Get-WmiObject -Class Win32_ComputerSystem -ComputerName $_.Name } | where { $_.UserName -eq "Domain\username" } | foreach { Get-WmiObject -Class Win32_NetworkAdapterConfiguration -ComputerName $_.Name } | where {$_.IPEnabled -eq $true } | Format-Table __SERVER, IPAddress

__SERVER                                IPAddress
--------                                ---------
MYCOMP                                  {192.168.99.18}

This one gives a table of the computernames and IP addresses that have the user logged in at the moment. Now the output does not have the username but I guess you know it already because you were searching for the name!

(I am also filtering out the network interfaces without IP address.)

The other issue is that it does not take terminal services logins. Don’t know of the top of my head how to add enumeration of those. Should be possible. This is the article I found that has the code doing that in C++: http://www.codeproject.com/system/logonsessions.asp

Tags: , , , , , , , ,

Revamped PowerGUI Library

We have revamped the PowerPack Library hosting dozens of useful PowerGUI extensions so it now lets you browse the categories rather than look through one big flat list.

One list was pretty handy in April when we were just starting but now with 27 packs already there and new one submitted by the community every few days search became the only way to find what you need.

So what we did was create a bunch of categories and put the existing packs in them. Here are the ones we have at the moment:

A lot of good stuff. All available for free and most of the packs posted by community members (with really few exceptions of packs by the PowerGUI team.)

Another good thing that I like about the packs is that they can actually show you how to use PowerShell to script against the systems.

For example, if you need to learn to manage SQL Server with PowerShell scripts you can download the SQL PowerPack, use it and at any time click the PowerShell Code tab to see/copy-paste the code you need.
If there’s something else we can do to make the site more convenient to use please comment here or in the site discussion forum.

Dmitry

Tags: , , , , , , , , , , , , , , , ,


My Recent Tweets

Legal

The posts on this blog are provided “as is” with no warranties and confer no rights. The opinions expressed on this site are mine and mine alone, and do not necessarily represent those of my employer - WSO2 or anyone else for that matter. All trademarks acknowledged.

© 2007-2014 Dmitry Sotnikov

June 2022
M T W T F S S
 12345
6789101112
13141516171819
20212223242526
27282930  

%d bloggers like this: