- De-provision the lab. Use the Stop-AzureVM and Export-AzureVM cmdlets in the PowerShell snippet below to shutdown and export lab VMs when they are not being used.
# Specify the Name of the VM to Export
$myVM = "XXXlabad01"
# Stop the VM prior to exporting it
Stop-AzureVM -ServiceName $myVM -Name $myVM
# Set the Export folder path for the VM configuration file. Make sure this folder exists!
$ExportPath = "C:\ExportVMs\ExportAzureVM-$myVM.xml"
# Export the VM to a file
Export-AzureVM -ServiceName $myVM -name $myVM -Path $ExportPath
# After you've confirmed that the Export file exists, delete the VM
Remove-AzureVM -ServiceName $myVM -name $myVM
- Re-provision the lab. Use the Import-AzureVM and Start-AzureVM cmdlets in the PowerShell snippet below to import and start lab VMs when needed again.
# Specify the Name of the VM to Import
$myVM = “XXXlabad01"
# Specify the Name of the Virtual Network on which to Import the VM
$myVNet = "XXXlabnet01"
# Specify the Import Path of the VM’s exported configuration file.
$ImportPath = "C:\ExportVMs\ExportAzureVM-$myVM.xml"
# Specify the Windows Azure Storage Account to be used.
$myStorageAccount = "XXXlabstor01"
Get-AzureSubscription | Set-AzureSubscription -CurrentStorageAccount $myStorageAccount
# Import the VM to Windows Azure
Import-AzureVM -Path $ImportPath | New-AzureVM -ServiceName $myVM -VNetName $myVNet
# Start the VM
Start-AzureVM -ServiceName $myVM -name $myVM
Following on from that we tested the migration from CRM 4.0 hosted CRM instillations to the newly configured test environment for CRM 2011.
We ran into a few problems (and a few things we did not know) and thought others may benefit from this.
CRM MigrationThe process was reasonably simple for us and for that reason we will just list the steps.
- Backup the CRM 4.0 database to file.
- On the new CRM 2011 SQL server, perform a normal SQL database restore from the backup file.
- Use the CRM 2011 deployment tool to “Import and Organisation”. Specifying the obvious settings for the database selection and user mapping. (In our case, we were on the same domain, so user mapping was easy).
Internally the org was accessible with https://internalcrm.domain.com/orgname but external access: https://orgname.domain.com:xxx failed.
First oneWas simple but only because we have seen it before. Originally we had accessed the org from our IE 9 browser with https://org.domain.com and accessed the CRM 4.0 IFD. Actually we used it for over a year.
Now we wanted to use the new IFD on CRM 2011, but on the same browser. We found when going to: https://org.domain.com:444 that the browser was not even rendering the request for user name and pass that we expected:
The IE failure gave no message or indication of why. Basically a 404 failure to hit anything useful.
Yet in another “real browser” (not IE) we could at least get prompted for user and pass info.
The CauseIE really sucks with clearing old data. The delete all / clear cache / remove cookies appears on the outset to dump everything, but it does not. In our case, it cached something from the previous connection to CRM 4.0 that was killing our access. We then also deleted data in “C:\Windows\Temp” Can’t explain what the cause is… I would just rather put it down to the fact that IE 9 “blow chunks” (big ones).
The solution is to manually navigate to the Temporary Internet Files directory under Windows, and manually delete everything you find in there. That fixes the page rendering issue.
More information here: http://www.interactivewebs.com/blog/index.php/crm/crm-2011-server-error-404-file-or-directory-not-found/
The Second One
Second, we entered a user name and pass, and received a message:
There was a problem accessing the site. Try to browse to the site again. If the problem persists, contact the administrator of this site and provide the reference number to identify the problem. Reference number: numbersThere was a matching set of AD FS 2.0 Event Logs that looked like this:
A token request was received for a relying party identified by the key ‘https://org.domain.com:444/default.aspx’, but the request could not be fulfilled because the key does not identify any known relying party trust.and
This request failed.
If this key represents a URI for which a token should be issued, verify that its prefix matches the relying party trust that is configured in the AD FS configuration database.
Encountered error during federation passive request.
Microsoft.IdentityServer.Web.InvalidScopeException: MSIS7007: The requested relying party trust ‘https://org.domain.com:444/default.aspx’ is unspecified or unsupported. If a relying party trust was specified, it is possible that you do not have permission to access the trust relying party. Contact your administrator for details.
at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.SubmitRequest(MSISRequestSecurityToken request)
at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.RequestBearerToken(MSISSignInRequestMessage signInRequest, SecurityTokenElement onBehalfOf, SecurityToken primaryAuthToken, String desiredTokenType, Uri& replyTo)
at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.RequestBearerToken(MSISSignInRequestMessage signInRequest, SecurityTokenElement onBehalfOf, SecurityToken primaryAuthToken, String desiredTokenType, MSISSession& session)
at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.BuildSignInResponseCoreWithSerializedToken(String signOnToken, WSFederationMessage incomingMessage)
at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.BuildSignInResponseCoreWithSecurityToken(SecurityToken securityToken, WSFederationMessage incomingMessage)
at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.BuildSignInResponseForProtocolRequest(FederationPassiveContext federationPassiveContext, SecurityToken securityToken)
at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.BuildSignInResponse(SecurityToken securityToken)
The solutionAn easy one, but something we did not know. With CRM 2011 in IFD. Each time you add an org, you need to update your Relying Party Trusts from Federation Metadata. Big words that mean…
- Open AD FS Management Tool
- Expand Trust Relationships
- Click on Relying Party Trusts
- Click on you IFD Trust, Right Click and Select Update From Federation Metadata
I have no idea why this is not automatically updated every time the service starts, or even every time the service is called upon….