I was trying to look at the ‘mail’ field on AD groups by running " get-adgroup -properties * ". After removing the information in the ‘mail’ field it no longer shows up as a property of the object when I rerun the command.
1 - Why do some unpopulated items show up and others (such as mail) do not?
2 - How do I run a commandlet and know for sure I am viewing ALL properties?
The command, for reasons never well-explained to me, only queries certain attributes. It particularly ignores extended-schema attributes. This is annoying, and there’s nothing you can do about it. For years, this is why people used Quest’s Get-QADUser instead, although that cmdlet (not “commandlet” [grin]) is long out of date at this point. You could perhaps revert to the old, COM-based ADSI interface, which PowerShell supports via the [ADSI] accelerator, although that can be a bit awkward. You could also dig into the underlying .NET Framework classes for querying AD, and perhaps write a better Get-ADUser cmdlet.
But you’ve got something else going on with “mail” in particular, and it has to do with the way the AD schema works. In this case, the attribute actually ceases to exist when it isn’t populated, whereas other attributes exist but are empty. You can’t “fix” this, because it isn’t “broken;” it’s by design. And because of that design, the answer to your second question is, “if the attribute doesn’t exist, then you won’t know it doesn’t exist, because it doesn’t exist, although when it does exist, it will exist.” I realize this is vexing, but it’s just the way the technology was built.
Guess when I think there might be a missing field I will have to double-check using ADSIedit and WMIexplorer.