Exchange 365 hybrid Remote move request- found yet another method for getting the operation could not be performed because the GUID could not be found.

Just when you think you've got the hang of your hybrid exchange deployment (on-premise and cloud), the cloud throws another curve ball at you.   I thought I had the process nailed down but apparently I forgot the old rule of 'order is important'.

Scenario:  You need to create a new user so you go to the AD controller and create or copy them.  Then I went to my DirSync server and forced a "Start-OnlineCoexistenceSync" and then waited a few minutes for it to finish.  Now at that point what I should have done was go to the on-premise Exchange server and created the new mailbox, and then ran DirSync.  Instead since I already had the office365.com admin portal up I went ahead and assigned a license to the user since the object was already sync'd up on the cloud.  When I went to submit a Remote Move Request of the mailbox from my on-premise server to the cloud, I got the friendly "The operation couldn't be performed because object couldn't be found on  .   At this point I hadn't figured out what I'd done wrong so I forced DirSync a few more times, unassigned the license, reassigned the license, etc.  In the end, I actually wound up having to delete the new AD account I'd created and do the whole thing over again but this time I created the local mailbox BEFORE I assigned a license in the cloud.  Apparently if you assign a license to the user and they don't have an Exchange GUID in their AD attributes yet, it hoses things up.  

Order:
1. Create AD user
2. Create local mailbox
3. Force DirSync
4. Move mailbox to the cloud
5. Assign a license in the 365 admin portal

Notes:
Steps 4 and 5 are interchangeable.
We create the mailbox locally first so that we retain the ability to move it back from the cloud to on-premise later if needed.  DirSync does NOT replicate a GUID created initially from the 365 cloud back to your local AD.

Migrating from on-premise BES on Exchange 2010 to Blackberry cloud services on office 365

I'd been waiting a very long time to finally be rid of my on-premise blackberry enterprise server and the blackberry cloud services (at the compelling price of free) was a light at the end of the tunnel for the office 365 upgrade.  But as you know, with Blackberry there are many things that can go wrong and most roads lead to phone wipes - which wasn't an option for me.

The initial activation was a piece of cake.  I just went into the office 365 admin portal and activated it under Service Settings -> Mobile.  Then waited 20 minutes as recommended on this guide:  http://www.proexchange.be/blogs/office365/archive/2012/03/08/migrate-from-on-premise-blackberry-enterprise-server-to-blackberry-business-cloud-services-in-office-365.aspx

Before proceeding I had all my blackberry users check to make sure they had the Enterprise Activation App installed.  

Then I added my first user and sent them the invite and migrated their mailbox to office 365.  At which point I found out that the user had never verified their blackberry ID so they couldn't download the app.  Oh, and they were on their last password attempt before it would wipe on them.   After having fixed that, we then tried the activation and it balked and told us to wipe the device because there was already another account on it.  Now wiping this particular employee's device was really just not an option.  So after digging around, I found a page that told us we could initiate an organization data only wipe from the BES console.

http://docs.blackberry.com/en/admin/deliverables/27983/How_device_deletes_work_data_1303191_11.jsp

"In the Device activation list, click Delete only the organization data and remove device. "

That worked properly and then we were able to get a little further along into the enterprise activation where it decided to get stuck forever while contacting the server.  To fix that, we just yanked out the battery for 30 seconds, then plugged it back in and tried again.  And voila - a fully functional blackberry on blackberry cloud services connected to an office 365 account.

remote move request not an accepted domain for your organization

So you've got your fancy Hybrid configuration all set up between your on-premise Exch 2010 SP3 server(s) and the office 365 cloud and you only get this error on some mailboxes.  Your dirsync is working fine, and your ADFS is even working for once.  Depending on your situation you may even have noticed that it's mostly older user mailboxes that are giving you grief.  In my case we used to have other domain names in use and when those were decommissioned, the extra Email addresses were never removed from the mailboxes.  For the Remote move to work, the only email address domains that can be attached to that mailbox have to be listed under the Domains tab in the office 365 admin page.  Once you remove the extras, then wait a while, then force a Dirsync, then wait a while and try again it'll go through.

Example:

UserA has these email addresses:
usera@contoso.com
usera@contoso.mail.onmicrosoft.com

UserB has these email addresses:
userb@contoso.com
userb@contoso.mail.onmicrosoft.com
userb@notcontoso.net

If the domains tab in office 365 only has contoso.com and contoso.mail.onmicrosoft.com, then UserA will move but UserB will fail.

Windows RT touch cover keyboard not working fix

So one of my managers got their brand new, shiny Windows RT units in today.  And the touch keyboard wouldn't work at all.  Of course, finding any hints online during the launch week of a new device is fun and after trying out several solutions such as re-docking, refreshing, and cursing profusely, we tried one last thing we saw on the forums - rubbing alcohol.
Yes, after seeing a post from rhalbert10 at http://forums.wpcentral.com/surface-windows-rt/199669.htm we grabbed a bottle of rubbing alcohol and some q-tip swabs and cleaned off both sets of shiny, brand new, untarnished, pristine looking connectors.  We let it air dry for 3 minutes and then redocked the touch cover.  And it started working fine...

Lync 2010 clients stuck in Offline state after patching

So after applying all the latest patches to my Lync 2010 server, my users started complaining that they were stuck in the Offline state but still 'connected'.  I noticed some errors in the event log related to SSL problems so after digging around I went into the Lync Deployment Wizard and ran the certificate wizard.  One of my external certificate entries was displaying as 'missing'.  After digging further I figured out that one of my certificates had expired but hadn't caused any problems so I hadn't noticed.  So I just installed an updated certificate and Assigned it using the wizard and shortly after all my Lync clients switched back to an Available status.

Scheduling non-humans in project 2010

So I was helping someone muddle through making a Project plan and ran into scheduling fun.  Some human performed tasks had to be scheduled with Predecessors that were computer days.  The humans only work monday-friday as opposed to the computers which ran 7 days a week.  I found several articles online that showed how to make a copy of the Standard calendar and they all said to change the days to include the weekends.  This seemed to work until we got a dozen or so entries into the plan and then it tried to schedule a Finish task on the same day as a Start for the same computer resource.  After fumbling around for a bit I figured out how to change the Display from just Date to Date and Time (00/00/00 00:00am/pm) and I noticed some odd start/stop times.  Ultimately the issue was that the Standard calendar Work week has the time defined as 08:00 to Noon and 13:00 to 17:00.  My cloned calendar had just been set to 08:00 to 17:00 which Project treated as a 9 hour work day and applied 8 hours of work which left a remainder.  So yes, now my computers get a lunch hour too and all is well.

Syncthru LDAP to 2008 active directory

I had the opportunity recently to work with one of the newer large multifunction Samsung copiers this month.  The Syncthru web interface is fairly feature rich but the documentation really could use more examples in some places.  My bane for 2 hours was figuring out how to populate the address book inside it by doing an LDAP pull from Active Directory.
The initial setup of the LDAP connector went through pretty quickly.  I just went to Security -> Network Security and then down to LDAP Server on the left menu.  I then clicked Add to enter in my LDAP server.  I added in the IP address of one of my domain controllers and then used Port number 3268 to start with because you want to keep it simple initially and introduction SSL LDAP would just add one more thing to troubleshoot.  Fill in your AD Domain name in DC=yourdomain,DC=com format.  Choose simple and enter in your username in DOMAINNAME\username format.  Note that this is the first oddity in that we're mixing netbios/domain name\username format and LDAP convention on the same form.

On the second half of that window, don't check the LDAPS yet!!!  

Click on the TEST button at the very bottom and make sure you get all OK/Success. 

Once that works, then click the Apply button at the top to save these settings.

So now we're halfway done and ready for the twists.  Go to the Address book and then click on the LDAP button at the top right.

Now for the GOTCHAS!   

a)  I couldn't get it to search recursively

b)  It only worked when the user account I used to authentication against AD was in the same ORG that I was searching.  (My AD is set to not allow anonymous searching so I have to use authentication)

c)  The login ID is in CN=firstname lastname format.  This is different than the domainname\username from the other LDAP screen.

d)  The search root is the full path to the exact ORG that you want to pull from. (note the OU=test, OU=US prepended)

To keep it simple, I used (mail=*) for my search filter.  Click on the Search button when done and IF you are successful, a list of people will show up.  Just click the Apply button to pull them all into the Address book (you can always delete the ones you don't want later from inside the copier).  If you botched it, you'll get Incorrect Filter errors.

Repeat for your other ORG units, remembering to use an account inside each one for the Login ID.  If you make it past the inconsistencies of the interface and the limitations of the AD implementation of LDAP you're home free.  Once you're done you'll have a fully functional Scan to Email function that works great.

LDAPS, php, windows server 2008 r2 and the Unknown CA error

It's never a good day when I have to use IIS and PHP in the same sentence.  I was trying to set up an open source program to do an LDAP auth to my Active Directory servers and it worked fine without encryption on port 389.  Since I'm not fond of passing credentials in clear text across networks, I then tried to set it up for LDAPS at which time it started failing.  I ran a wireshark capture on it and the glaring fatal error of "Unkonwn CA" reared it's ugly head.  After spending considerable time making sure my AD certificates were up to date, the CA cert was imported to the local machine's certificate store, and several LDP.exe tests just to make sure, I turned my attention to figuring out how to make ldap skip past that error.  PHP had been installed using the microsoft platform installer so of course very little matched up with most of the articles I found since folders like c:\openldap\sysconf don't exist, much less then LDAP.conf file whose location appears to shift depending on which DLL your install came with.
Anyway, the key I needed was TLS_REQCERT never which would tell ldap to go fly a kite if it didn't like the CA.

So yes, that's all that you have to put in the ldap.conf file and then save it out as type "All Files" so notepad doesn't attach a hidden .txt to your filename.  Depending on your DLL, you'll either need to drop it in the root of your inetpub drive or in c:\openldap\sysconf.  Or do like I did and just dump it in both places.  Then run an IISRESET or reboot the server and voila, LDAPS starts working.

Yes, it is slightly less secure since it's not checking the CA but at least it's not clear text.