Wednesday, November 21, 2012

Accessing Windows Azure blob storage

I have some files transferred to a container in my storage account. Now on a new VM, I need to access these files, but do not have CloudXplorer since .NET has not yet been installed. So I turned to the StorageClient module and Powershell.

Import-Module Microsoft.WindowsAzure.StorageClient.dll
$storageAccountName = 'my storage account'
$accessKey = 'my access key'
$storageCredentials = New-Object Microsoft.WindowsAzure.StorageCredentialsAccountAndKey($storageAccountName, $accessKey)
$storageAccountEndpoint = "http://$storageAccountName.blob.core.windows.net/"
$blobClient = New-Object Microsoft.WindowsAzure.StorageClient.CloudBlobClient($storageAccountEndpoint, $storageCredentials)
$filename = "my file"
$blob = $blobClient.GetBlobReference($filename)
$localFilename = "local filename"
$blob.DownloadToFile($localFilename)

References:
CloudBlob.DownloadToFile
Microsoft.WindowsAzure.StorageClient


Edit 2013-04-05
This is based on the 1.0 Storage Client. Updated script can be found in an updated post on Windows Azure Storage through Powershell

Friday, November 16, 2012

User Profile Synchronization not synchronizing email address

I found this on my new SP 2013 installation. After a user profile synchronization, my email addresses were not coming over from AD. Doing some poking around, I found that the user profile property was not mapped to the correct attribute.
To correct:

  1. Go to Central Administration->Manage Service Applications.
  2. Go to your User Profile Service Application
  3. Go to Manage User Properties
  4. Scroll down to Work email (under the Contact Information Section)
  5. Edit Work email
  6. Remove the existing Property Mapping for Synchronization mappings. They were inexplicably set to proxyAddresses (aCSPolicyName).
  7. Add new mapping to the mail attribute
  8. Start a Profile Sync
  9. Save and OK

It looks like just a simple profile sync would not work. You actually have to update the email addresses of each user and then do a sync. Argh!



Thursday, November 15, 2012

UserProfileApplicationNotAvailableException System.TimeoutException

I have a service the frequently accesses the User Profile Service Application. Intermittently, I would get the following:
Error generating SyndicationItem for ActivityEvent 0B275DAC41FD141CB2382AAE5987540D  Microsoft.Office.Server.UserProfiles.UserProfileApplicationNotAvailableException: System.TimeoutException    
 at Microsoft.Office.Server.UserProfiles.ProfileDBCacheServiceClient.GetUserData(UserSearchCriteria searchCriteria)    
 at Microsoft.Office.Server.UserProfiles.UserProfileCache.GetUserData(UserProfileManager objManager, Nullable`1 recordId, Guid gAcct, String strAcct, Byte[] bSid, String strEmail, Boolean doNotResolveToMasterAccount)    
 at Microsoft.Office.Server.UserProfiles.UserProfile.RetrieveUser(String strAcct, Guid gAcct, Byte[] bSid, Nullable`1 recordId, Boolean doNotResolveToMasterAccount, Boolean loadFullProfile)    
 at Microsoft.Office.Server.UserProfiles.UserProfile..ctor(UserProfileManager objManager, Int64 recordId)    
 at Microsoft.Office.Server.UserProfiles.UserProfileManager.GetUserProfile(Int64 recordId)

I tried the following to confirm:
$app = Get-SPWebApplication
$site = Get-SPSite $app.Url
$context = Get-SPServiceContext $site
$upm = New-Object Microsoft.Office.Server.UserProfiles.UserProfileManager($context)
$upm.UserExists('someuser')

... and it just hangs.

Since this is a demo machine, there could be many factors:
1. Not enough resources
2. Application pool crash
3. Database not responding
4. General UPA flakiness
5. All of the above (and possibly pointing to #1 as the root cause).

I tried stop/start on the UPS and UPSS, then an iisreset. This didn't fix the problem. However, a reboot did.

Further looking at the event logs, I do see the following events from MsiInstaller that might be suspicious:


Detection of product '{90140000-104C-0000-1000-0000000FF1CE}', feature 'PeopleILM', component '{1C12B6E6-898C-4D58-9774-AAAFBDFE273C}' failed.  The resource 'C:\Program Files\Microsoft Office Servers\14.0\Service\Microsoft.ResourceManagement.Service.exe' does not exist.
Detection of product '{90140000-104C-0000-1000-0000000FF1CE}', feature 'PeopleILM' failed during request for component '{9AE4D8E0-D3F6-47A8-8FAE-38496FE32FF5}'
Failed to connect to server. Error: 0x80070005
Detection of product '{90140000-104C-0000-1000-0000000FF1CE}', feature 'PeopleILM', component '{1C12B6E6-898C-4D58-9774-AAAFBDFE273C}' failed.  The resource 'C:\Program Files\Microsoft Office Servers\14.0\Service\Microsoft.ResourceManagement.Service.exe' does not exist.
Detection of product '{90140000-104C-0000-1000-0000000FF1CE}', feature 'PeopleILM' failed during request for component '{1681AE41-ADA8-4B70-BC11-98A5A4EDD046}'
Failed to connect to server. Error: 0x80070005

... followed by one from FIMSynchronizationService:

The management agent "MOSS-3692cc7e-f3bf-4090-ae09-a552d3c61b7e" completed run profile "MOSS_DELTAIMPORT_4adf3894-708b-4ae2-ab9f-60438a49cae1" with a delta import or delta synchronization step type. The rules configuration has changed since the last full import or full synchronization.
 
User Action
To ensure the updated rules are applied to all objects, a run with step type of full import and full synchronization should be completed.

It was patch Tuesday a couple of days ago, perhaps that had a factor since I have auto updates enabled (which curiously did not install).