Tim Tressel, Author at Perficient Blogs https://blogs.perficient.com/author/ttressel/ Expert Digital Insights Sun, 20 Jan 2013 23:51:45 +0000 en-US hourly 1 https://blogs.perficient.com/files/favicon-194x194-1-150x150.png Tim Tressel, Author at Perficient Blogs https://blogs.perficient.com/author/ttressel/ 32 32 30508587 How to Combine PowerShell Cmdlet Output in a Single CSV File https://blogs.perficient.com/2013/01/20/how-to-combine-powershell-cmdlet-output-in-a-single-csv-file/ https://blogs.perficient.com/2013/01/20/how-to-combine-powershell-cmdlet-output-in-a-single-csv-file/#comments Sun, 20 Jan 2013 23:51:45 +0000 http://blogs.perficient.com/microsoft/?p=10778

If you have been working with Office 365, you have probably been extracting mailbox data and exporting it to CSV for various reporting tasks. You may have also gone further and attempted to pipeline data from multiple Cmdlets into Export-CSV. Let’s use the following scriptlet as an example:

Get-Mailbox Test.user1@company.com | Get-MailboxStatistics | Select Alias,Displayname,TotalItemSize,ArchiveStatus | Export-CSV C:\test.csv

Now the problem with the previous scriptlet is that the data from the first command Get-Mailbox will not be displayed in the CSV output, and only the Get-MailboxStatistics data is shown. In the following image, notice that the Alias and Archivestatus columns are blank:
tressel_excel
So how can we combine multiple Cmdlets’ output data into one CSV file? The following snippet stores data from Get-Msoluser, Get-MailboxStatistics, and Get-Mailbox Cmdlets using a hash table and an array, before exporting to CSV. For the sake of brevity, I will assume that you already have PowerShell V2, you are connected via Remote PowerShell to Exchange Online, and the Microsoft Online Service Module before using this snippet.

$DataPath = "C:\o365UserData.csv"
$Results = @()
$MailboxUsers = get-mailbox -resultsize unlimited
foreach($user in $mailboxusers)
{
$UPN = $user.userprincipalname
$License = Get-MsolUser -userprincipalname $UPN
$MbxStats = Get-MailboxStatistics $UPN
      $Properties = @{
      Name = $user.name
      UPN = $UPN
      Alias = $user.alias
      UsageLocation = $user.usagelocation
      License = $License.Licenses[0].AccountSkuId
      ArchiveStatus = $user.archivestatus
      Server = $MbxStats.servername
      DatabaseInstructions = $MbxStats.databasename
      TotItemSize = $MbxStats.totalitemsize
      }
$Results += New-Object psobject -Property $properties
}
$Results | Select-Object Name,UPN,Alias,UsageLocation,License,ArchiveStatus,Server,DatabaseInstructions,TotItemSize | Export-Csv -notypeinformation -Path $DataPath

Now let’s take a look at how our CSV file looks using this new method (separated into two pictures):
excel5
excel6
You can see that the new CSV file contains the missing data from the first attempt, as well as more data from the 3 Cmdlets.

]]>
https://blogs.perficient.com/2013/01/20/how-to-combine-powershell-cmdlet-output-in-a-single-csv-file/feed/ 3 224226
Avoiding PowerShell Session Conflict with Office 365 https://blogs.perficient.com/2012/12/07/avoiding-powershell-session-conflict-with-office-365/ https://blogs.perficient.com/2012/12/07/avoiding-powershell-session-conflict-with-office-365/#respond Fri, 07 Dec 2012 16:49:00 +0000 http://blogs.perficient.com/microsoft/?p=10206

As more and more companies move to Office 365, PowerShell Cmdlets and Scripts are becoming staples of  Administrator toolsets. One issue that I have come across quite often is the Cmdlet overlap that occurs when using Remote PowerShell sessions to both Office 365, and Exchange 2010 on-premises simultaneously.
For example, let’s say that I have a hybrid environment with both Exchange 2010 mailboxes on-premises, and mailboxes in Office 365. If I wanted to use PowerShell to collect data from both environments using Get-Mailbox, there is a conflict because both environments use the Cmdlet. So what is the solution to this problem? Well one way would be to import, then remove sessions as as needed. This does work, but it is quite a cumbersome solution. Instead, adding a prefix while importing a session has proven to be a much easier solution to manage and execute.
The Import-PSSession Cmdlet contains a parameter named -Prefix which allows you to add a prefix to the noun portion of Cmdlets that are imported with a session. For an example scenario, I’ll first create an Exchange 2010 on-premises Remote PowerShell Session:

$ExOnPremSession = New-PSSession -configuratonName Microsoft.Exchange -ConnectionURI http://ExchangeCasServer.domain.com/PowerShell/ -Authentication kerberos -WarningAction Silentlycontinue

Then I’ll import the on-premises session:

Import-PSSession $ExOnPremSession -Warningaction silentlycontinue

Now that my on-premises session is connected, I will create a session to Office 365:

$CloudSession = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell -Credential $CloudCredential -Authentication Basic -AllowRedirection -WarningAction SilentlyContinue

Then I will import the session using the chosen prefix “Cloud” :

Import-PSSession $CloudSession -Prefix Cloud -DisableNameChecking

Now if I want mailbox data for a user that is in Office 365, I can use my new prefix Cmdlet:

Get-CloudMailbox Test.User1 | FL

I can use any other Cmdlet offered for Office 365 Remote PowerShell too, just by attaching my prefix to the noun portion of the original Cmdlet:

Get-CloudMailboxStatistics
Set-CloudMailbox
Get-CloudActiveSyncDeviceStatistics

And if I need to get mailbox data for a second user on-premises I can use the original Cmdlet:

Get-Mailbox Test.User2 | FL

So, even though I have multiple sessions imported with overlapping Cmdlets, I can still issue them to the proper platform with a simple prefix on each Cmdlet. This functionality has greatly simplified my Office 365 PowerShell scripts as they become more complex.

]]>
https://blogs.perficient.com/2012/12/07/avoiding-powershell-session-conflict-with-office-365/feed/ 0 224204