In the box:
They both come with the same things in the box (strap, manual and pouch), the strap for the 15x50’s is bigger, better quality and the Canon logo is embroidered vs printed on the 12x36’s.
The 15x50’s came with a little Guarantee card, 10 years for the binoculars, 1 year for the electronics and electrics.
 
The 12x36’s case has a zipper and a strap, the 15x50s have a clip and flap where you pass the strap from the bins.
Construction:
The 15x50’s have a more rubbery feel because they actually have a rubber coating, whereas the 12x36’s have matt cool rubber texture, but not actually rubber… I prefer the feeling of the 12x36’s.
The 15x50’s are significantly heavier and fatter, whereas the 12x36’s fit snuggly in my hand.
Canon doesn’t seemed to have been concerned about the weight of the 15x50’s, if I look through the objective I can see biggish phillips screws, solder points and a mostly metal construction. Looking through the 12x36’s it looks mostly sturdy plastic.
The 15x50’s are also stiffer everywhere, adjusting the dioptre and intraocular separation is quite stiff on the 15x50’s and quite smooth on the 12x36’s.
 
 
 
 
Chances are you’ve read that the eyecup (eyepiece rubber) on the 15x50’s is horrendous, it’s not as nice as on the 12x36’s, but it’s not too bad. The eyecups are unnecessarily big, and don’t hug your eye sockets well. If you have a large nasal bridge this maybe an issue.
I’ve been toying with the idea of adding some neoprene around the outer part of the eyecup to create a horn shape eyecup for a more enclosed feeling
 
The rubber, like everything else about the 15x50’s is stiffer.
A big bonus with the 15x50’s is that they have a standard thread tripod mount, this is essential for astronomy. Sure you could make/buy a support for the 12x36’s, but it’s nice not needing to.
The objective optical or antireflective coating of the 15x50’s reflects a purple light, whereas the 12x36’s a green light… so the lens looks purple or green. I’m not sure which is better, but the 10x42 L’s are also green.
The 15x50’s are supposed to be weather proof (haven’t tested), so this may prevent them from fogging up when going from a cold dry place to a warm humid place and maybe last longer.
12x36 IS II weight with 2xAA battery: 706gr
15x50 IS AW weight with 2xAA battery: 1208gr
Performance:
I was very surprised that the 15x50’s don’t appear to magnify much more than the 12x36’s, they magnify stars by about ~10%. With terrestrial objects I can’t discern much, if any difference in magnification, and certainly not the expected 20%.
But what they do allow is better resolution; by resolution I mean I am able to resolve the detail of the object better. I did a couple reading tests with both, and with the 15x50’s I was able to read words that were impossible to decipher with the 12x36’s.
Example: I had a can of furniture polish on the other side of the house, and I started looking with the 12x36’s, I could easily read the large writing, but I focused on a small area that looked like:
Sdlvvmt Ahvco
Oem him
IhttbnHy
With the 15x50’s after steadying myself and trying I was able to see it said:
Solvent Abuse
Can Kill
Instantly
The words didn’t look any bigger, just clearer.
Now here’s an area that may interest you, that isn’t in the official specs and hasn’t been written about (AFAIK)… close focus distance; the 15x50’s focuses closer @ 4.30m vs the 12x36’s @ 5.72m.
Both exhibit some minor chromatic aberration, I’m not sure which is worse. With the 12x36’s looking at Jupiter and equating it to the face of a clock there’s a largish white>purplish deformity at the 5 o’clock position. With the 15x50’s there’s a smaller red colour band at 5 o’clock and another small green band at 10 o’clock, there’s also a faint light halo that extends significantly from ~12 o’clock to ~3 o’clock.
Depending how you position your eyes to the eyepiece this changes slightly. Looking at Jupiter and it’s moons the 15x50’s also produce a much brighter image ~30%, as you might expect from the 33% larger objective.
 
 
 
Image stabilization:
Is stabilization even necessary? YES.
I read the 12x36’s have better IS and the spec’s give it an extra 0.1 degrees, so I kept thinking they were better; but in practise there is no discernable difference. You have to keep the button pressed with the 12x36’s which is no big deal, and with the 15x50’s you can either keep it pressed and when released it will disengage, or you can press once and it will stay on for 5 minutes or turn off with another press. The manual says the 12x36’s battery last 4hrs, and 2.5hrs for the 15x50’s.
I’ve also read that the image becomes blurry when you engage the IS… with both I may very slightly adjust focus… but I found myself doing the same with IS not engaged. I think it’s a natural consequence of verifying you have the best focus possible… I wouldn’t classify this as an issue.
The 15x50’s make a click noise when the IS is engaged, kind of like a solenoid actuator.
Conclusion:
In day to day use there is very little difference between the two. I have both Canon’s 70-300mm lenses, and I would equate the 15x50’s with the L version. The 70-300mm L won EISA Pro Lens 2011, but I think there’s very little difference between it and the non L. It’s bigger, heavier, stiffer, looks more Pro (white), weather sealed, produces slightly sharper images and costs 75% more.
But this is the case with everything, producing something 5% better costs a lot more.
In brief, there’s minimal noticeable difference in magnification, but the 15x50’s give a clearer image.
If money is of no concern and you don’t mind the weight, the 15x50’s are better.
If you want to carry a pair of bin’s, on safari, the zoo, whale watching the 12x36’s will make you happy.
If you want to look at Jupiter (always looks the same, but the moons move), then the 15x50’s will make you twice as happy because they’re clearer and have a tripod mount.
Which would I keep? I’m a sucker for performance, so I find myself reaching for the 15x50’s, but I sure wouldn’t want to travel far with them.
The score:
12x36 IS II: 88/100
15x50 IS AW: 92/100
It's pretty simple to add XPS indexing/support to a SharePoint 2010 search, but even so some people struggle. So just to make things real easy for you, I created a PowerShell script.
What you need to do:
- Logon to the server that's running SharePoint Server Search 14
- Copy the PowerShell script from below (some of it runs under right navigation)
- Paste it in to a text file > save as whatever.ps1.
- Run the PowerShell script.
Import-Module servermanager
$xps = Get-WindowsFeature XPS-Viewer
If ($xps.Installed -eq $FALSE)
{
Add-WindowsFeature XPS-Viewer
}
If ((Get-PsSnapin |?{$_.Name -eq "Microsoft.SharePoint.PowerShell"})-eq $null)
{
$PSSnapin = Add-PsSnapin Microsoft.SharePoint.PowerShell -ErrorAction SilentlyContinue | Out-Null
}
Write-Host -ForegroundColor White "- Adding registry values ..."
New-Item -path "HKLM:\SOFTWARE\Microsoft\Office Server\14.0\Search\Setup\Filters\.xps"
New-ItemProperty "HKLM:\SOFTWARE\Microsoft\Office Server\14.0\Search\Setup\Filters\.xps" -Name "Extension" -value "xps" -PropertyType String -Force | Out-Null
New-ItemProperty "HKLM:\SOFTWARE\Microsoft\Office Server\14.0\Search\Setup\Filters\.xps" -Name "FileTypeBucket" -value "1" -PropertyType dword -Force | Out-Null
New-ItemProperty "HKLM:\SOFTWARE\Microsoft\Office Server\14.0\Search\Setup\Filters\.xps" -Name "MimeTypes" -value "application/xps" -PropertyType String -Force | Out-Null
New-Item -path "HKLM:\SOFTWARE\Microsoft\Office Server\14.0\Search\Setup\ContentIndexCommon\Filters\Extension\.xps"
New-ItemProperty -path "HKLM:\SOFTWARE\Microsoft\Office Server\14.0\Search\Setup\ContentIndexCommon\Filters\Extension\.xps" -Name "(Default)" -value "{1E4CEC13-76BD-4ce2-8372-711CB6F10FD1}" -PropertyType MultiString -Force | Out-Null
Get-SPEnterpriseSearchServiceApplication | New-SPEnterpriseSearchCrawlExtension "xps"
Stop-Service "OSearch14"
Start-Service "OSearch14"
Issue: The My Site of [USER] is scheduled for deletion.
The My Site of [USER] is scheduled for deletion in 3 days. As their manager you are now the temporary owner of their site. This temporary ownership gives you access to the site to copy any business-related information you might need. To access the site use this URL: http://mysites/personal/[USER]
Cause:
- User profile deleted
- User profile re-imported
- User profile has its Personal site property missing
There's a Timer Job that runs every hour called My Site Cleanup Job. This job among other things looks at dbo.Profile_DeletedUsers and My Sites that don't have a current user profile association.
When it finds a My Site without a user profile association it adds the site to the dbo.MySiteDeletionStatus table in the Profile DB.
Fix:
- Ensure the User Profile has the site associated with his account
The following query will give you profiles with a My Site.
SELECT PropertyVal, p.*
FROM dbo.UserProfileValue v
inner join dbo.UserProfile_Full p on p.RecordID=v.RecordID
where PropertyID=22 and PropertyVal is not null
If the account isn't there you need to go to: Central Administration > Manage User Profiles and add the URL to the Personal site property.
- Delete the MySiteDeletionStatus record.
This table has a NotificationStatus column with values 1-3 calculated based on the Created column.
1 = 14 days til deletion email, 2 = 3 days til deletion and 3 = 1 day til deletion.
This last step is the only crucial one.
BTW: This theoretically will leave the Db in an unsupported state, because we're not supposed to edit or even query SP DB's directly... so don't tell anyone and no one will know.
Issue:
Log Name: Application
Source: Microsoft-SharePoint Products-SharePoint Foundation
Date: 15/07/2011 12:00:31 AM
Event ID: 5586
Task Category: Database
Level: Error
Keywords:
User: ray
Computer: SPS2010
Description:
Unknown SQL Exception 2812 occurred. Additional error information from SQL Server is included below.
Could not find stored procedure 'proc_UpdateStatisticsNVP'.
Cause:
After the June 2011 CU I started getting this error every night in the logs.
A quick search through \Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\SQL
showed [dbo].[proc_UpdateStatistics] was calling this proc.
So I assume where ever I find [dbo].[proc_UpdateStatistics] I should also find [dbo].[proc_UpdateStatisticsNVP]
Fix:
The fix requires that each DB that has [dbo].[proc_UpdateStatistics] also have [dbo].[proc_UpdateStatisticsNVP] the following SQL Query will help you identify the DB's:
exec sp_msforeachdb 'if exists(select name from [?].sys.objects where type = ''P'' and name like ''%proc_UpdateStatistics%'') AND not exists(select name from [?].sys.objects where type = ''P'' and name like ''%proc_UpdateStatisticsNVP%'') select ''?'''
This will give you the DB's that have [dbo].[proc_UpdateStatistics] but don't have [dbo].[proc_UpdateStatisticsNVP] then all you need to do is create the proc using an existing one...
OK, easy is relative, but it if you don't mind making a couple XML configuration files, it's as easy as easy gets with Folders2SP PowerShell script.
Folders2SP Codeplex Project
Before writing the script I evaluated a number of products, but I found non offered the flexibility I wanted and at ~$2500 I reasoned I could do better; hence Folders2SP. Sure it doesn't have a UI and it doesn't support Permission migration... but it's free, 42kb, doesn't soil your production servers, no custom web services (for item level permissions) and you can extend it to your hearts content... so you can add a permissions method.
Description
Folder2SP.ps1 is a PowerShell script which helps you migrate documents from SharePoint and folder structures to SPS2010 while preserving versions, metadata and converting folder names to managed metadata terms.
Use case: You have documents in a MOSS library and in a network share folder structure which need to be migrated to a SPS 2010 library. You want to use the words in the folders as taxonomy terms in your SPS2010 library and perform regular expressions on the file name/path.
Case setup
In this example we're going to get some documents from MOSS document library "Documents", and along with the sample documents included in this package upload them to a "Codeplex" document library in a SPS2010 site.
- Create a working directory either on the SPS2010 server or a network share Eg: C:\Folders2SP.
- Extract the contents of this project to your working directory. You should have Folders2SP.ps1, run.ps1, codeplex.xml and a "files" directory with some more directories and text files.
- Create a destination document library in you SPS2010 site eg: Codeplex.
- Add the required fields to the document library eg: Year (choice with 2008-2011), Enterprise Metadata field (site settings > Enterprise Metadata and Keywords Settings), LibMeta1 (Managed Metadata single), LibMeta2(Metadata multi), LibMeta3(Metadata multi) and connect them to an appropriate termset or term.
-
Modify the example codeplex.xml. Use your own MOSS library (works with a SPS2010 document library too).
- Lookup site: the site you want to get the documents from. The script uses web services. To interrogate the source site I recommend you try my FireWS script , cos it rocks.
library: the library to get the files from.
view: if you want specific files, enter the view Guid here.
rootfolder: is the folder to look in... default is the name of the library.
- Target site: is the only attribute you need to change for this demo.
- The xml file is commented so you know the options.
Process overview
- Run PowerShell as Administrator (make sure your execution policy is set to remote) from your SPS2010 server, run.ps1 includes Folder2SP.ps1 and calls the function Folder2SP passing Codeplex.xml as the configuration file.
- Folder2SP loads the config file, assigns a bunch of variables and creates a log file.
- Goes to http://spsdev/documents and starts traversing the library... if you get access denied, it's your fault, try running the scripts from C:\ or use a local MOSS library.
- Downloads all files it finds to the "Folders" path
- Loops through all the files in Folders path and (if replicatefolders=true) recreates the folder hierarchy on the SPS document library.
- Connects the Lookup site
- Gets Metadata
- Downloads versions to the working directory
- Uploads the file to the Target document library
- Loops through each field and check if it's configured in the xml config file. This is an inefficient way of doing it, but the script started out as just a way to copy all field data from the Lookup to the Target.
- If it's a taxonomy field, it looks up the value, if it can't find the value it creates it. There are a couple options here, so read the comments in the example xml config file.
- It then loops through the "Field" "Value"s and performs logic associated with Value type. I've only created 3 Value types "FileDate" uses properties from the file, "RegEx" takes an expression and matches on the full file name, and "Lookup" uses a value from the Web Service call.
- If there's a user field it will 1st attempt to find the user, if it can't find them it will attempt to add them, if that fails it uses the account who's running the script.
- Sets the new item value.
- At the end you should have a migration report, and all the files from the Lookup site and your Folder path in the SPS2010 library with the metadata.
To do
- View Fields ($wsFields) for the web service call should be moved to the XML config file.
- Permissions could be also migrated if a item level permissions web service were available on the Lookup server.
- Improve error handling, and more consistent variable naming.
- Improve xml config file
- Add more field type handlers
You're here because you're trying to find away of comparing values of a record before or after saving it in an event receiver, and BeforeProperties and AfterProperties are giving you null, right? Well chances are you searched and found posts about saving the values to a cache, and a lot of other rubbish... I know I did.
Anyway the proper way of doing things is real simple, and I stumbled upon it using Powershell to check my event receivers.
SPEventReceiverDefinition has a Synchronization property.
An Asynchronous event passes the objects to another thread and you lose the BeforeProperties and AfterProperties.
A Synchronous event keeps the thread and you can access the BeforeProperties and AfterProperties.
In my case after specifying the event receiver as Synchronous I was able to compare existing values with values in properties.AfterProperties on an Receiver Type = ItemUpdating.
So to set a Receiver as Synchronous, just add Synchronous to your definition (elements.xml) or in code set the Synchronization property.
Eg:
<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
<Receivers>
<Receiver>
...
...
<Synchronization>Synchronous</Synchronization>
</Receiver>
</Receivers>
</Elements>
Hello my friend!
Me and you obviously have something in common; we've experience the joy of configuring SharePoint 2010's User Profile Synchronization Service.
You've read all the other blog post's and now you're here. There isn't much I can tell you that you probably haven't read... most of the issues are caused by not following Microsoft instructions: http://technet.microsoft.com/en-us/library/ee721049.aspx#StartUPSSProc, and the fact that Forefront Identity Manager (FIM) is a PoS :)
One of the most important lines is:
After the User Profile Synchronization service is started, the farm account is no longer required to be an administrator on the synchronization server. To improve the security of your SharePoint Server installation, remove the farm account from the Administrators group on the synchronization server.
That means the account HAS to be in the local Administrators group before you can start it.
Other things to take in to consideration:
- In a multi-server farm "Network Service" and SP account which is starting the User Profile Synchronization Service should also have (Component Services) Local Launch and Activation rights on:
- Forefront Identity Manager Controller Object {36574FCB-E5F2-4C55-AA06-146B2B8FBD95}
- Forefront Identity Manager Management Agents {10B6A600-6EE8-44F3-AC02-2CA42B08A2B5}
- Forefront Identity Manager Script Host Loader {76032766-22CF-497D-BA0D-4F0583F05D15}
- Forefront Identity Manager Synchronization Service {835BEE60-8731-4159-8BFF-941301D76D05}
- A quick way to make sure your account has rights to launch FIM Synchronization Service is to login using the account and run C:\Program Files\Microsoft Office Servers\14.0\Synchronization Service\UIShell\miisclient.exe
- Verify there is only 1 ForefrontIdentityManager Trusted Root Certificate
Winows Key + R (run): mmc > Ctrl + M > Certificates > Add > Computer Account > Local
If there are more delete ALL of them and restart the service from Central Admin.
- Verify that both ForeFront Identity Manager services are set to Automatic and the Log On As identity is your SP account.
- Make sure the SP account is an owner or at the very least FIM_SynchronizationService of the User Profile Sync DB's
- Give the "Network Service" account read/execute rights to "C:\Program Files\Microsoft Office Servers\14.0" directory.
- Check the Application Pool is running and/or Recycle it.
It will be the App Pool which is running "C:\Program Files\Microsoft Office Servers\14.0\webservices\Profile"
- Try reinstalling FIM it's in your SP2010 install
SPS2010\Global\Ppl\pplwfe.msi
There's an update in the December 2010 CU "pplwfe-x-none.msp"
- If you have set NetBiosDomainNamesEnabled on the User Profile Service application to True you may get Error: Unable to process Create message when you try a new Configure Synchronization Connection if you installed the SP2010 December 2010 CU; in this case you're stuffed and it's broken until MS release the Feb 2011 CU.
To enable netbios names read: http://blogs.msdn.com/b/spses/archive/2010/04/01/sharepoint-2010-provisioning-user-profile-synchronization.aspx
- User Profile Synchronization Service suck on "Starting"
Try running the "ProfileSynchronizationSetupJob" timer job, then check the Timer Job Status page... chance are the Progress is 0%
I've had this issue and I went home came back the next day and it was done.
- ProfileSynchronizationSetupJob is stuck on "Pausing"... Delete the Timer service cache.
Read: http://support.microsoft.com/kb/939308/en-us
- If you've tried all of the above it's now time to do what you've been holding out on... yup trawl through the damn logs.
- Read: http://blogs.msdn.com/b/spses/archive/2010/12/02/guide-to-user-profile-service-application-upa-part-2-setting-up-the-user-profile-service-application.aspx
- Enable verbose logging for the Microsoft.ResourceManagement.Service.exe and SharePoint Portal Server > User Profiles
- Don't be afraid of restarting the server... with any luck it might all just work after.
|
|