One of the challenges when using PowerShell for automation is handling authentication for the connection to various Office 365 services. Running a script as a scheduled task means that it needs to be able to use a set of stored credentials to authenticate to Office 365. Storing passwords in scripts is obviously not a good idea, because the passwords could easily be exposed if the script is obtained by another person who uses the same computer, or by accidentally sharing it online (such as on GitHub) with the creds still included.

Another challenge is constantly need to access the passwords to login. I keep my Office 365 admin credentials in a password database, and hopefully you use one as well (LastPass, 1Password, KeePass, Dashlane, etc). This makes it easy to have multiple credentials (such as admin accounts for different tenants, or for different tiers of administrative privilege) that each have unique, complex passwords. Thanks to web browser plugins for the likes of LastPass and 1Password it’s easy to login to Office 365 web-based portals, but copying and pasting passwords into PowerShell authentication prompts gets quite tedious.

I solve both of those problems by storing credentials on my admin workstation. This requires no special tools; it can achieved by using built-in PowerShell functionality. If the idea of storing credentials on your computer sounds like a security risk, please read on.

First, let’s look at how you might typically connect to Office 365 using PowerShell. The Connect-MsolService cmdlet will connect you to an Office 365 for management tasks such as assigning a license to a user.

1	PS C:\Scripts>Connect–MsolService

The cmdlet will prompt you for credentials to use for authenticating the session.

To avoid that credential prompt for repeat connections, you can use Get-Credential to capture your username and password as a credential object in PowerShell first, and use that for subsequent commands. For example:

1 2 3 4 5 6 7

PS C:\Scripts> $credential = Get–Credential   cmdlet Get–Credential at command pipeline position 1 Supply values for the following parameters: Credential   PS C:\Scripts> Connect–MsolService –Credential $credential

That solves part of the issue (repeatedly entering credentials), but doesn’t solve the issue of managing multiple accounts (should you create several credential objects every time you open a PowerShell console?) or running scheduled tasks (since you won’t be there to answer the credential prompt for the script).

But what we can do is store the password from the credential to a file on our computer. The password value is stored in memory as a secure string, and can be encrypted and stored in a text file, for example:

1	PS C:\Scripts> $credential.Password | ConvertFrom–SecureString | Out–File C:\Scripts\Keys\demoaccount.txt

The text file contains the encrypted value, which will look something like this.

Now, at this point you may be concerned that anyone who has access to that file could decrypt the password. Fortunately, that’s not the case. The ConvertFrom-SecureString cmdlet encrypts the password using the Windows Data Protection API. In short, this means that only the user who encrypted the password can decrypt it again, and they can only do so on the same computer that it was encrypted on. If the text file is accessed by another person, or by the same user on a different machine, they’ll be unable to decrypt it.

1 2 3

PS C:\Scripts> $securestring = Get–Content C:\Scripts\Keys\demoaccount.txt | ConvertTo–SecureString   ConvertTo–SecureString : Key not valid for use in specified state.

Of course, you should still protect the files from being accessed by others, in much the same way you’d protect your SSH keys or your password database. For example, store them in a location on the workstation that is not included in cloud storage or backups, and is on a Bitlocker encrypted disk.

The downside of this approach is that you won’t be able to simply copy your stored credentials to another computer. Instead, you’ll need to recreate them on the new computer, which is not a huge hassle since you only need to do it once. There is another approach that avoids this problem, but it has other caveats. I’ll go into that in a separate article some other time.

So now that you can see how passwords can be securely stored and retrieved, how can this technique be used to manage stored credentials for day to day use, as well as for scheduled tasks? I’ve written some PowerShell functions that make it easy.

Preparation Tasks

The two functions that I’ve written use a variable named $KeyPath, and I recommend you add that variable to your PowerShell profile. If you don’t, the functions will prompt you for a path to save or retrieve credentials from, and that’s just going to get annoying.

Download the script containing the two functions, and run it to load the functions in your PowerShell console. I recommend adding them both to your PowerShell profile as well so that you can re-use them in any PowerShell session.

1	PS C:\Scripts> . .\Functions–PSStoredCredentials.ps1

Storing a New Credential

The first function will save a new stored credential. Simply run New-StoredCredential and enter the username and password when prompted.

The credential will be saves as a file named username.cred in the path that you configured for $KeyPath.

Using a Stored Credential

You can list the stored credentials in your $KeyPath folder by running Get-StoredCredential with the -List parameter.

1 2 3

PS C:\Scripts> Get–StoredCredential –List Username: admin@exchangeserverpro.onmicrosoft.com Username: admin@tenant.onmicrosoft.com

Get-StoredCredential can also be used to retrieve the stored credential and save it as a variable to then use with a cmdlet that requires authentication, for example:

1 2 3

PS C:\Scripts> $Credential = Get–StoredCredential –UserName admin@tenant.onmicrosoft.com   PS C:\Scripts> Connect–MsolService –Credential $Credential

You can also use Get-StoredCredential in a one-liner like this.

1	PS C:\Scripts> Connect–MsolService –Credential (Get–StoredCredential –UserName admin@exchangeserverpro.onmicrosoft.com)

The difference between the examples above and the use of Get-MsolService earlier in this post, is that using the stored credential avoids the need to respond to an authentication prompt. So your passwords can be unique and complex without you needing to remember them or copy/paste them from a password manager.

And it’s not just for connecting to Office 365 services. You can use the stored credentials for pretty much any PowerShell cmdlet that uses credentials.

1 2	PS C:\Scripts> $credential = Get–StoredCredential –UserName administrator@exchangeserverpro.net PS C:\Scripts> Invoke–Command –ComputerName 10.1.4.3 –Credential $credential {Get–Service}

If you try to use a credential that doesn’t exist, you’ll simply get an error.

1 2	PS C:\Scripts> Connect–MsolService –Credential (Get–StoredCredential –UserName foo@exchangeserverpro.onmicrosoft.com) Unable to locate a credential for foo@exchangeserverpro.onmicrosoft.com

Using a Stored Credential for a Scheduled Task

The Get-StoredCredential function can also be easily integrated into scripts that you are running as scheduled tasks. The most important thing to remember is that the password can only be decrypted by the user account that encrypted it in the first place.

If your scheduled tasks run using a service account, you’ll need to log on as that service account to run New-StoredCredential, or use Runas to launch a PowerShell console as the service account. The stored credential file will also need to be located in a folder that the service account can access, and that location needs to be defined as $KeyPath in your script as well.

Download the New-StoredCredential and Get-StoredCredential Functions

The script to load the functions is available on GitHub. Comments and feedback are welcome in the comments below, or you can raise an issue on GitHub if you find a bug or have a suggested improvement to the script.

Source: http://practical365.com/blog/saving-credentials-for-office-365-powershell-scripts-and-scheduled-tasks/

Improving customer service requires focus and hard work. You need to promote the right things throughout the organization, and especially among the workers who frequently interact with customers. The right training is key to rolling out a successful program. And what’s exiting, and perhaps somewhat intimidating, is the acceleration of new technologies that are changing the game of customer service.

This infographic highlights important aspects of good customer service practices and how the growth of new technology is creating efficiencies.

This infographic is provided by Cube Marketing

Questions: What steps are you taking to improve customer service? You can leave a comment in the space below.

—
The Product Management Perspective: As the product manager you want happy customers. You depend on the support team, sales reps and consultants to touch all your customers, and you likely get frustrated you can’t spend more time with them. You are in a key role for customers, and the work you do to create the right products for your customers will pay dividends as you move forward.

Source: http://wp.me/p9pgp-OX

Believe it or not, Microsoft has joined The Linux Foundation as a Platinum member. No, this isn’t The Onion and it’s not April Fool’s Day. Microsoft has joined The Linux Foundation.

Virgin Atlantic’s Founder Richard Branson-backed startup Boom has unveiled a supersonic jet-prototype named ‘Baby Boom’, that covers 5500 km distance between New York and London in just 3.5 hours. A passenger plane usually takes at least 6.5 hours to cover the same distance.

Netherlands-based doctors have performed the first-ever brain implant on a 58-year-old woman paralysed by Lou Gehrig’s disease, enabling her to communicate in day-to-day life via a speech computer. The disease-caused nerve degeneration had left her with control only over her eyes.

Taiwanese electronics maker Acer on Tuesday launched ‘Swift 7’, the world’s thinnest laptop with a thickness of 9.98 mm in India at a price of ₹99,999. The laptop weighs 1.1 kg and features a 13.3-inch display with 8 GB memory and 256 GB internal storage. The laptop is thinner than HP’s 10.

The recently launched Google Pixel phone has been hacked by the Chinese hackers just in less than a minute! A team called White-Hat hackers from Qihoo 360, which participated in the 2016 PwnFest hacking competition in Seoul did the impossible in less than 60 seconds.