November 2011 - Posts

When creating PowerShell cmdlets for any Microsoft technology - WMI, Exchange, Lync, etc. - it is common to need to provide credentials that are different from the default credentials. This can be even more important when you are using PowerShell remoting to connect to a remote computer.

However, using the built-in cmdlet Get-Credential causes a dialog box to be opened on the console! (And it will simply fail in some cases, when the internal PowerShell $host.UI.PromptForCredential interface has not been implemented.) This is certainly not something that you want to happen when your PowerShell script is being called with remote PowerShell or from a service, or in many other scenarios.

The solution is to pass in the full credential, already containing the secure password and the user names and (optionally) the domain or a user principal name. This is a bit challenging, as the constructor for a secure string doesn't provide you an option for passing in an entire password. Therefore, you must build the secure string one character at a time.

The two functions below make the process easy.

Note: the $username parameter to newPSCredential can be in several formats: a plain username, a domain\username, or username@domain.com, or computername\username (for a local user).

Note 2: some functions want a NetworkCredential instead of a PSCredential. Creating one of those is as simple as changing System.Management.Automation.PSCredential to System.Net.NetworkCredential.

Note 3: as a security best practice, after you call the newPSCredential function, you should ensure that the plain text password is no longer available in the calling routine.

Enjoy!

function newSecurePassword( [string]$password )
{
                ###
                ### newSecurePassword
                ###
                ### Take the normal string password provided and turn it into a 
                ### secure string that can be used to set credentials.
                ###

                $secure = new-object System.Security.SecureString

                $password.ToCharArray() |% { $secure.AppendChar( $_ ) }

                return $secure
}

function newPSCredential( [string]$username, [string]$password )
{
		###
		### newPSCredential
		###
		### Create a new PSCredential object containing the provided
		### username and plain-text password.
		###

                $pass = newSecurePassword $password

                $cred = new-object System.Management.Automation.PSCredential( $username, $pass )

                $cred
}

Until next time...

If there are things you would like to see written about, please let me know.

Posted by michael | with no comments
Filed under: , ,

At Exchange Connections 2011 in Las Vegas, Greg Taylor of Microsoft made a comment about some schema changes coming in Exchange 2010 Service Pack 2, that were enabling potential future feature content. This led to interest on my part to investigate those changes further.

It's worthwhile to note that the Exchange Team at Microsoft allows schema updates to occur during service pack upgrades, but not during Update Rollups. This could potentially allow the Exchange Team to create schema changes that wouldn't have any support in the cmdlets released for the service pack, but cmdlets could be modified and improved in Update Rollups.

The Exchange Team has actually already released the schema changes that are coming in Exchange 2010 Service Pack 2. You can download a copy of these changes in the Exchange Server Active Directory Schema Changes Reference, October 2011.

The information contained in the document is very Active Directory oriented. So if you aren't very familiar with the AD Schema you may find the information confusing.

There are several very interesting items.

  1. The Mail-Recipient class has now gained the Company and Department attributes. 

    This means that Groups (both security groups and distribution groups) and Contacts (mail contacts) can now be assigned values to the Company and Department attributes.

    From a technical perspective, the Mail-Recipient class is a system auxiliary class, for both the Group and Contact classes, and all attributes present in Mail-Recipient are available in them.
  2. The ms-Exch-Custom-Attributes class has gained 35 new custom attributes, from ms-Exch-Extension-Attribute-16 to ms-Exch-Extension-Attribute-45, and ms-Exch-Extension-Custom-Attribute-1 through ms-Exch-Extension-Custom-Attribute-5. 

    This means that Contacts, Groups, Users, Public Folders, Dynamic Distribution Lists, and Recipient Policies all now have a huge number of new attributes that can be assigned arbitrary values by an organization. This is welcome news to organizations who are using many or most of the current custom attributes and are wary to extend the schema themselves. 

    From a technical perspective, the ms-Exch-Custom-Attributes class is an auxiliary class for all the named classes above.
  3. Many new attributes and classes were added to provide support for Address Book Policies and to enhance access to various address lists, global address lists, and offline address lists maintained by Exchange.

    The master class is ms-Exch-Address-Book-Mailbox-Policy.
  4. There are several new attributes and one new class (ms-Exch-Coexistence-Relationship) that are probably designed to support the Hybrid Coexistence Wizard and to overall simplify the process of configuring hybrid coexistence with Exchange Online.
  5. There is a new class (ms-Exch-ActiveSync-Device-Autoblock-Threshold) and a number of new attributes that are within that class that appear to be designed to support automatic throttling of ActiveSync devices. However, that new potential feature was not discussed in Microsoft's blog post on Announcing Exchange 2010 Service Pack 2.

Along with the above changes, various MAPI IDs were added to provide access to the above attributes and classes from within MAPI applications, and new OIDs were assigned to each of the new attributes and new classes.

While cmdlets may or may not appear in service pack 2 to manipulate all of these objects and attributes, they are welcome additions and will be available for organizations to utilize in custom programs.

Until next time...

If there are things you would like to see written about, please let me know.