I’ve had a lot of trouble recently with connecting my PC to my SharePoint Online tenants via PowerShell. The process is fairly simple and this article is the best starting point: http://technet.microsoft.com/en-us/library/fp161388(v=office.15).aspx.
Having done all the right things, I was running into the following error upon every time I’d run the Connect-SPOService cmdlet: “The Application ID (AppID) for which the service ticket is requested does not exist on the system.”
I don’t know what that means or where to begin with it, so I hit the web and found nothing useful. Ugh.
Well, today I got lucky. I’m presenting at tonight’s meeting of the Phoenix Office 365 User Group and have been spending a few precious lunchtime minutes prepping for tonight. In particular, the facility we meet in does not provide wired network access and so I want to make sure that my virtual machines work are going to play nicely with my wireless NIC today. I disabled my Ethernet NIC and am only on wireless now as I write this.
Somehow, that fixed the issue. I’m guessing it has something to do with my host (Windows 8.1) running Hyper-V and having several different virtual switches that share my wired Ethernet NIC.
I’m now essentially not using any unusual network settings and I’ve been able to connect to multiple tenants now without a problem. Yay!
Update 01/05/15
I just called and talked to tech support at my ISP and the “The Application ID (AppID) for which the service ticket is requested does not exist on the system” message is occurring because I’m on a residential network instead of a business network. Looks like I’ll have to go to the office for these kinds of things. Argh!
Update 02/02/16
I’ve found success in connecting to my company’s VPN for the last year. While that’s worked, it’s been pain in the neck to connect to VPN on and off all day. Today Max Melcher posted a similar article here: https://melcher.it/2016/02/for-security-reasons-dtd-is-prohibited-in-this-xml-document. Check it out. You might find success in some DNS updates and disabling IPv6.
If you aren’t familiar with sed and grep you may want to stop reading here.
If you are and this is bringing Unix flashbacks, you should read on. I started my career on Unix systems and quickly found that grep and sed were just part of getting the job done and I ended up using them for pretty much everything.
When I started working with PowerShell and I was piping output around I found myself quickly missing good old sed and grep.
As a quick summary, grep just matched something in the text. As an example, directory a file pipe it to grep for part of the name of the file that you were looking for.
Sed provided a way to quickly replace a value within a file with something else (such as replace all instances of XYZCO with ABCCO).
A filter to perform grep
From this blog post I found that you can define a filter which you can then use to perform something like grep. His filter is as follows:
filter grep($keyword) { if ( ($_ | Out-String) -like “*$keyword*”) { $_ } }
Using the blog post concept, I was able to build a similar filter for sed. The following is my filter:
filter sed($before,$after) { %{$_ -replace $before,$after} }
For examples of this let’s start with grep – the PowerShell below lists all services which include the word “Background”
Get-Service | grep Background
Or another example of this, listing all SCOM classes which include the word database as shown below (get-scomclass | grep database).
Or a search for all SCOM classes which include “SQL Database” (get-scomclass | grep “SQL database”).
Sed examples
For examples of this let’s go next to sed – the PowerShell below lists all processes and changes the reference to w32time to Timer.
Get-Service | sed w32time Timer
Summary: By putting these filters into the top of my scripts (or using them when I launch PowerShell) I’ve been able to take most of the times where I would need a grep or a sed and utilize this approach to accomplish the same type of functionality.
Additional reference:
http://powershell.com/cs/blogs/tips/archive/2010/06/18/replace-text-in-files.aspx
http://blogs.msdn.com/b/zainnab/archive/2007/07/09/grep-and-sed-with-powershell.aspx
http://opensysblog.directorioc.net/2013/03/emulating-sed-command-with-powershell.html
This blog post goes through the following:
- What is currently in maintenance mode?
- Removing all objects from maintenance mode
What is currently in maintenance mode?
To see what is currently in maintenance mode the following two approaches are available. The first option is not as usable from an output perspective but works well when removing items from maintenance mode. The second shown below provides a more readable format.
Get-SCOMMaintenanceMode
Get-SCOMMonitoringObject | where-object {$_.InMaintenanceMode -eq $true}
Removing all objects from maintenance mode
The following single line PowerShell script will take any objects currently in maintenance mode and remove them from maintenance mode:
Get-SCOMMaintenanceMode | Set-SCOMMaintenanceMode –EndTime (Get-Date) –Comment “Autoremoved from maintenance mode”
The graphic below shows how the PowerShell script runs when removing all items from maintenance mode and the results of re-checking what is in maintenance mode using the Get-SCOMMaintenanceMode command (no results indicating that there are no longer any objects which are in maintenance mode in this management group).
_________________BEGIN Connect.ps1________________________
$LiveCred = Get-Credential
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $LiveCred -Authentication Basic –AllowRedirection
Import-PSSession $Session -AllowClobber
connect-msolservice -credential $LiveCred
#Remove-PSSession $Session
__________________END Connect.ps1_________________________
The above script connects to two services: (1) Azure Active Directory remote powershell and (2) Exchange Online remote powershell.
This is useful because the former is required to assign and manage licenses to Dirsync’d users in Office 365, and the later is required for managing mailboxes and mailbox moves in Exchange Online.
By combining the two sessions into a single powershell session, it is easier to administer and only have a single powershell window open.
One of the most common misconceptions about mailbox moves to Exchange Online with powershell is that people do not realize that you must run the move in a remote powershell session (see move script below for an example).
One of the most common tasks when getting started with Office 365 is to bulk license users based on a CSV file containing email addresses. The maintenance script below was created to perform multiple actions based on a source CSV file.
___________BEGIN Maintenance.ps1 ___________________
Import-csv c:\users.csv| foreach {
$UPN = $_.email
#The line below is great for testing the CSV file match against Cloud UPN. Helps you understand if your CSV file email addresses are matched up perfectly against cloud UPN addresses.
#get-Msoluser -UserPrincipalName $UPN
#the next line is great for getting unlicensed users. This helps you identify any unlicensed users that need a license applied.
#get-msoluser -UserPrincipalName $UPN | where {$_.IsLicensed -eq $false}
#The line below sets usage location and is required for every user.
#set-msoluser -userprincipalname $UPN -UsageLocation US
#The next two lines assign licenses. In order to get <tenant name> you run this command: get-msolaccountsku (remove the <>)
#$MSOLSKU = “<tenant name>:ENTERPRISEPACK”
#Set-MsolUserLicense -UserPrincipalName $UPN -Addlicenses $MSOLSKU
}
___________END Maintenance.ps1 ___________________
Now that you have licensed your users, it is now time to move mailboxes! (Assumes you have already completed the steps in the Exchange Deployment Assistant for configuring a Hybrid environment).
_______________Move Script.ps1_______________
#When prompted, enter your on-premise AD username and password like Domain\User that is a member of the Exchange Organizational Admins group
#Remember – this script is to be called from within a remote powershell session against Exchange Online, not using your on-premise Exchange Management shell!
$cred = get-credential
Import-csv .\user.csv | foreach {
$UPN = $_.Email
New-MoveRequest -identity $UPN -Remote -RemoteHostname ‘myhybridserver.mydomain.com’ -RemoteCredential $cred -TargetDeliveryDomain ‘mytenantname.mail.onmicrosoft.com’ -BadItemLimit 100 -AcceptLargeDataLoss -LargeItemLimit 100 -SuspendWhenReadyToComplete
}
_______________End Move Script.ps1_______________
Tips and Tricks
- After you’ve completed the tasks you wanted to perform in the Exchange Online organization, you need to disconnect the session between your local computer and the Exchange Online organization.
Use the following command to disconnect remote PowerShell from the Exchange Online organization.Remove-PSSession $Session
If you close the remote Windows PowerShell window without following this procedure, the session will have to time out (in approx 15 minutes), and the quota for the maximum number of concurrent connections may prevent you from connecting back to the service on a timely basis (maximum of 3 connections are allowed)
2. If you are setting up a new o365 tenant, and your on-premise AD domain has a default UPN like “myad.local” then you can configure Directory Sync to use an alternate login ID such as the mail attribute so that the email address is mapped to the UPN field in o365. This is beneficial because it saves the effort of changing UPN Id’s on-premise!
Recent change to Dirsync
It is also important to note that starting with DirSync version 6862.0000 released on June 5 2014 there is no longer a DirSyncConfigShell Console file in the Program Files folder. Instead you just start a normal PowerShell window and run Import-Module DirSync. After that the Start-OnlineCoexistenceSync cmdlet is available.
Common Dirsync Questions
- Even though Dirsync is configured to sync by default once every three hours, you can manually force dirsync to run at any time.
- You can also configure the default interval to run in shorter increments
- The default interval for Dirsync is a completely separate interval than password synchronization. Passwords are synced immediately to Azure AD and the average time before they are effective is usually under 3 minutes.