I was recently asked how to add user information – specifically first and last name – into computer description in Active Directory.
First get your user
$user = Get-ADUser -Identity FredBrown
Then add the information to the computer’s description
Set-ADComputer -Identity W10ProIp -Description “Used by $($user.Givenname) $($user.Surname)”
You need to use the subexpression – $() – syntax to resolve the values rather than getting references to the $user object.
Then test the description has been set
Get-ADComputer -Identity W10ProIp -Properties Description
if it was me I’d add the samAccountName or other unique identifier as name isn’t sufficient to uniquely identify the user
Further to my last post it appears that Install-Module in PowerShell v6.2 RC1 DOESN’T follow the rules. In an elevated session if the scope parameter ISN’T used it will install to $home\Documents\PowerShell\Modules
The default appears to be CurrentUser regardless.
You have to use -Scope AllUsers if you want it to install in C:\Program Files\PowerShell\Modules
Be aware of the Scope parameter when using Install-Module. The following rules apply:
Allusers scope installs to $env:ProgramFiles\PowerShell\Modules
CurrentUser scope installs to $home\Documents\PowerShell\Modules
– – For an elevated PowerShell session, Scope defaults to AllUsers
– – For non-elevated PowerShell sessions in PowerShellGet versions 2.0.0 and above, the Scope is CurrentUser
– – For non-elevated PowerShell sessions in PowerShellGet versions 1.6.7 and earlier, Scope is undefined, and Install-Module fails
PowerShell v6.2 RC 1 uses PowerShellGet 2.0.4 and PowerShell v6.1.3 uses version 1.6.7. You’ll see different behavior depending on PowerShell version so the advice is to use the Scope parameter to ensure the module goes where you intend.
I usually want my modules in Program files (Allusers) rather than my documents folder (CurrentUser).
The lesson seems to be to use the Scope parameter rather than relying on defaults
The release of PowerShell v6.2 release candidate 1 brings more experimental features including PSTempDrive.
You can view the currently available experimental features using get-ExperimentalFeature. You’ll find a total of four:
Install PSTempDrive using
Enable-ExperimentalFeature –Name PSTempDrive
Restart PowerShell after enabling the feature.
Get-PSDrive will show a new drive named Temp. The root of the drive is set by the path in your TEMP environmental variable.
You can use and access the TEMP drive like any other drive set by PowerShell.
The TEMP drive follows the pattern of other drives created from a path on an existing drive using the filesystem provider in that the used and free space figures reflect the situation for the whole volume not the individual drives. The free space is OK like this as theoretically you could consume the whole of the available space on your new drive but the used space should reflect reality. The C: drive used space should be for the whole volume but the TEMP: drive should only show the space used in your TEMP folder etc.
If you want to remove the experimental feature – use Disable-ExperimentalFeature and restart PowerShell.
Not wholly convinced of the need for this particular feature but it gives marginally easier access to the TEMP folder.
Remember that experimental features are just that – experimental – and could be modified or even removed in a later version of PowerShell
PowerShell v6.2 release candidate 1 is available – https://github.com/PowerShell/PowerShell/releases
The only breaking change is to how Join-String works in a non-pipeline scenario. That shouldn’t be a big issue as Join-String is new to v6.2.
The security fixes from v6.1..3 have been incorporated in the release candidate.
Experimental features gets a couple of new options round creating a TEMP:\ drive and suggestions given when a command isn’t found
Following my last post about sample questions for PowerShell interviews that I’d stumbled across I’ve been asked what sort of questions I’d ask – given my statement that many of the question sets were out of date.
I’ve thought about it and decided I’ll run an occasional series of questions and the information I’d expect.
Before I start that I’ve thought some more around the whole issue of PowerShell interviews and there are some things to think about before jumping into performing an interview.
The most important thing is what are you interviewing for. What exactly does the role entail? There are a number of possibilities:
You want a PowerShell developer – the person will spend all of their time writing and maintaining code. Requirements and and specifications will be given to them. for this sort of role you’ll need to be mixing developer technique questions in with the powershelll questions.
You want someone to automate your administrative processes. Again development techniques ae going to feature alongside PowerShell questions. Ideally, you’d also want some one who would question the processes because automating what you have now is necessarily the best thing. I can remember being asked to generate a report about some products when I worked for a financial services organisation. Easy enough to do. I then asked 1 question – what was the report used for. It turned out that the data on the report was keyed into another system. The job then became extract data from system a and feed into system b and produce a report of what happened. That single question saved the users a bunch of time, effort and reduced errors from the re-keying of data.
You want an administrator who can also automate the administration of some or all of your environment. At this point you’re looking for someone who can administer X (or a bunch of Xs) and write PowerShell code that’ll make that job easier. You need to ensure that the person actually understand the system[s] as well as PowerShell.
Once you know the sort of person you want its time to think about the questions to ask. I’m going to assume that any other questions and just concentrate on questions about PowerShell from a theoretical and practical perspective. If you can sit the candidate down and make them write some code for you – but we’ll get to that another time.
For some bizarre reason I ended up looking at various sets of PowerShell interview questions and answers.
For the most part they scared me – due to their outdated nature.
Many, if not most, of the question sets hadn’t been brought up to date for PowerShell v5.1 and very few even mentioned v6.x. The remoting and CIM answers were often misleading.
And that’s just what I picked up on a quick scan through.
Bottom line is that if you need to prepare for an interview and you’re going to get PowerShell questions then make sure that you actually know the subject and don’t rely on dubious online sources.