info here regarding vcenter 5.5 update 1a:
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2076692

set the registry value AutoEndTasks to 1 under HKEY_USERS\.DEFAULT\Control Panel\Desktop

source:
http://geeksaresexy.blogspot.com/2006/05/forcing-unresponsive-applications-to.html

GAL changes are immediately visible from OWA, however the offline address book (OAB) won’t reflect the change until the next OAB update interval. the interval is configured from the EMC->Organization Configuration->Mailbox->Offline Address Book. there’s also an option to right-click the OAB and select Update (i haven’t tried this yet).

to get the latest copy of the OAB from an outlook client go to the Send/Receive tab->Send/Receive Groups->Download Address Book.

more info here:
http://www.petenetlive.com/KB/Article/0000775.htm

change the following…
Name attribute = userPrincipalName
User filter = (userPrincipalName={0})
Login (DN)s add “{1}”, the default is “{0}\{1}” where {0} is netbios domain name and {1} is username

i upgraded to ubuntu 14.04 not too long ago. after booting up 14.04 for the first time and starting a gnome flashback session, i was immediately perplexed as to why i was seeing the unity launcher. it’s most likely because i use the flashback session with effects enabled (compiz) enabled, but still it was strange that i was looking at the unity launcher right next to the gnome classic launcher.

to disable the unity launcher i installed the compizconfig settings manager and disabled the “Ubuntu Unity Plugin”. this worked immediately however the top portions of each program window disappeared after disabling unity. the solution was to reenable the “Window Decoration” effect in the compizconfig.
source: http://askubuntu.com/questions/134172/window-title-bars-missing-occasionally-in-unity

something very cool that i came across during reading 14.04 articles was pipelight. pipelight is somewhat of an evolution of the netflix-desktop idea. however, instead of relying on a windows browser, pipelight allows you to use a linux web browser along with a windows version of a browser plugin (most notably silverlight). i tried netflix w/ firefox and it seemed to work fine.

summarized steps to install pipelight:
sudo apt-add-repository ppa:pipelight/stable
sudo apt-get update
sudo apt-get install pipelight-multi

sudo pipelight-plugin –enable silverlight
sudo pipelight-plugin –enable widevine

then for firefox i installed the add-on “UAControl” and set the user agent string to:
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20100101 Firefox/22.0
pipelight info source: http://www.webupd8.org/2013/08/pipelight-use-silverlight-in-your-linux.html
more pipelight info: http://www.makeuseof.com/tag/easily-enable-silverlight-watch-netflix-linux/

chromium and adobe flash usage seemed kind of messed up in 14.04. i followed the instructions for installing pepper flash and that seems to have resolved the issue.
installation:
sudo apt-get install pepperflashplugin-nonfree
sudo update-pepperflashplugin-nonfree –install
source: http://www.webupd8.org/2014/01/pepper-flash-player-installer-for.html

concluding thoughts…not really much to say. i noticed two longstanding packages have been removed from the repository – abuse (the game) and chmsee. virtualbox continues to be awesome.

regarding the future of ubuntu…i believe if canonical is dead set on using mir instead of wayland (and not including a wayland option) then i’ll probably have to switch to another distro. i see wayland becoming somewhat of an unofficial standard amongst linux distros and it doesn’t make sense for canonical to ignore that and go it alone. the good news is that mir supposedly isn’t debuting until 2016. i’m also concerned on the mobile “convergence” stuff coming in ubuntu 14.10. hopefully, none of that will be disruptive for me.

if i had to change distros again i’d probably take a hard look at mint. i’ve messed around with it before, but i’ve always been bothered by the fact that they don’t officially support/encourage online release upgrades. i’d also consider opensuse…

i have done this once with no apparent consequences…
http://support.microsoft.com/kb/889250

update 4/21/2014:
the utility pkiview.msc that comes with the windows server 2003 resource kit can be used to determine the health of a CA.

had an issue with my test ADFS instance and office365, where federated logins were redirecting to the public URL for the production ADFS farm.

to resolve:
Get-MsolFederationProperty -DomainName [federated domain] – this displays the current federation info for ADFS & office365
Update-MsolFederatedDomain -DomainName [federated domain] – run this if the above info is outdated/incorrect
^may need to add “-supportmultipledomains” to this command
sources:
http://www.proexchange.be/blogs/office365/archive/2011/11/06/how-to-change-the-adfs-2-0-url-in-a-deployment-used-with-office-365.aspx
http://support.microsoft.com/kb/2647048

i’ve linked to an article before on how to convert a federated domain back to a standard domain, but here’s the exact command:
Convert-MsolDomainToStandard -DomainName [federated domain] -SkipUserConversion $true -PasswordFile c:\password.txt
(skipuserconversion would be set to false if you had no plans to refederate the domain)

list of *Msol* cmdlets: http://msdn.microsoft.com/en-us/library/azure/jj151815.aspx

customize ADFS 3.0…can now only be done with powershell cmdlets. the web files are evidently embedded inside of a DLL now and cannot be edited directly (like they could w/ ADFS 2.0)
list of commonly used cmdlets: http://technet.microsoft.com/en-us/library/dn280950.aspx

the A2 license SKUs for wave15 are:
<office 365 tenant>:STANDARDWOFFPACK_STUDENT
<office 365 tenant>:STANDARDWOFFPACK_FACULTY

test ADFS signin: https://fs.mydomain.com/adfs/ls/idpinitiatedsignon
ADFS federation metadata URL: https://fs.mydomain.com/federationmetadata/2007-06/federationmetadata.xml

change UPN of office365 user:
Set-MsolUserPrincipalName -UserPrincipalName [current username]@myfederateddomain.com -NewUserPrincipalName [current username]@office365tenant.onmicrosoft.com
then…
Set-MsolUserPrincipalName -UserPrincipalName [current username]@office365tenant.onmicrosoft.com -NewUserPrincipalName [new username]@myfederateddomain.com

at some point update the on-prem AD user to reflect the changes. if done beforehand dirsync will throw a sync error regarding this user.
source: http://community.office365.com/en-us/f/613/t/50201.aspx

a couple of days ago i tried to mount a pre-formatted SD card on my laptop running the latest ubuntu release. the SD card attempted to auto-mount, but then presented an error “…mount: unknown filesystem type ‘exfat'”. the solution was thankfully very simple. install the packages exfat-utils and exfat-fuse. no reboot required.

source:
http://askubuntu.com/questions/364270/mount-unknown-filesystem-exfat

steps:
create new token signing cert on primary ADFS server by running…
Add-PSSnapin Microsoft.Adfs.Powershell
Update-ADFSCertificate -CertificateType Token-Signing (or Token-Decrypting)
(this creates a secondary certificate that should be auto-rolledover to when the primary certificate expires)
check ADFS settings with the powershell cmdlet Get-ADFSProperties
check value of AutoCertificateRollover property (should be true or false)

to update the office365 relying party data, run:
Connect-MSOLService
Update-MSOLFederatedDomain –DomainName:[federated domain] –supportmultipledomain (from azure active directory powershell module)

^note: if you receive “sorry, but we’re having trouble signing you in” and “error: 80041317” when trying to login to office365 this is a sure sign that the above command needs to be ran.

relying parties that utilize ADFS metadata will not need a copy of the new certificate, other relying parties will.

sources:
http://blogs.technet.com/b/sharepoint_made_easy/archive/2013/03/21/certificate-error-for-federated-domains-on-o365.aspx
http://support.microsoft.com/kb/2713898
http://support.microsoft.com/kb/2647048http://nikpatel.net/2014/12/22/renew-expired-adfs-token-certificates-for-adfs-2-0-and-sharepoint-2013-on-premises/

long over due update 9/11/2014:
the certificate rollover did not go as expected. the certificate rollover did not occur until 3 or so days after the original cert’s expiration date. this makes me feel like the auto rollover feature is unreliable.

disabling auto rollover:
Set-ADFSProperties -AutoCertificateRollover $false

if auto rollover is enabled you are unable to manually make the new certificate the primary
http://virtualizationtechno.blogspot.com/2014/02/set-as-primary-option-is-greyed-out-in.html

update 3/17/2015:
precise directions…
1. generate new token-signing cert
2. disable auto rollover
3. set new cert to primary
4. restart the adfs service on each system
5. get new metadata or cert to RPs
6. run Update-MSOLFederationDomain command for office365
7. reenable auto rollover

update 4/8/2015:
next year i’m going to update the token-decrypting certificate at the same time to hopefully avoid any possibility of a future ADFS issue. after changing out both certs i plan on restarting the ADFS services on both internal servers and then restarting the services on the proxies.

update 9/24/2015 (updating the service communications certificate):
import the new certificate through the usual means and then grant the ADFS service account read access to the certificate’s private key. then from the ADFS GUI use “set service communications certificate” and choose the new cert. it seems like that would be it, but it isn’t.

run Get-AdfsCertificate to get the thumbprints of the current certificates. Get-AdfsSslCertificate can be used as well but in my case it was reporting the thumbprint of the old cert. once the correct thumbprint is located run Set-AdfsSslCertificate -thumbprint [thumbprint]. at this point the new certificate is visible from a web browser, however, it’s recommended to restart the adfs services anyways.

on ADFS WAP systems use Get-WebApplicationProxySslCertificate and Set-WebApplicationProxySslCertificate and restart the services on the WAPs. some sources mention that this command must be ran as well: Get-WebApplicationProxyApplication -Name “[name]” | Set-WebApplicationProxyApplication -ExternalCertificateThumbprint [thumbprint]
^confirmed that Set-WebApplicationProxyApplication must be ran. to retrieve the web application proxy application name run Get-WebApplicationProxyApplication | fl

sources:
http://blogs.technet.com/b/tune_in_to_windows_intune/archive/2013/11/13/replace-certificates-on-adfs-3-0.aspx#pi47623=2
https://blogs.blackmarble.co.uk/blogs/adawson/post/2015/02/13/Changing-the-Certificate-on-ADFS-30-and-Web-Application-Proxy-(WAP).aspx
http://scug.be/sccm/2015/06/04/how-to-replace-expired-certificates-on-adfs-3-0-the-right-way/

update 8/12/2016:
a few months back i needed to add a new ADFS node to the farm and was blocked by the existence of an expired token-signing certificate. the error message displayed by the new node makes it seem like the certificate problem is with the new node; however, this is not the case as the issue is actually with your existing ADFS farm members. i couldn’t find a way to remove the certificate via the management GUI. when running Get-AdfsCertificate i could see the offending certificate listed and grab its thumbprint.

i then ran the following to remove the expired certificate:
Set-AdfsProperties -autocertificaterollover $falseRemove-AdfsCertificate -thumprint [thumprint] -certificatetype token-signing
Set-AdfsProperties -autocertificaterollover $true

and the expired certificate was removed. no down time was caused by this.

source: https://social.technet.microsoft.com/Forums/office/en-US/3e56f2bf-b885-4de0-bf88-5b50acbcfea5/adfs-joining-an-existing-federation-server-farm-error-cannot-find-certificate-i-do-not?forum=winserverDS

i ran into problems with the VDP 5.1 to 5.5 upgrade. i had the 5.5 iso mounted on the appliance and the upgrade was in process. everything appeared to be going well…

the upgrade mentions that it can take several hours to complete which i actually thought was an exaggeration. i left the process running at approx. 6:00pm and checked back a little later after 8:00pm. when i logged in to check the upgrade status i was surprised to see VDP backup jobs running in vcenter. i found it pretty strange yet figured it could be possible the appliance was rebooted after the upgrade had finished. i went to the vdp-configure URL to check things out and found that the upgrade had actually stalled, most likely caused by the backup jobs kicking off. so mistake on my part…i’ve just gotten used to installs automatically stopping services/jobs.

my initial reaction was to just try the upgrade again, but the vmware recommendation was to roll back with the snapshots. you’re forced to create snapshots for the appliance prior to the upgrade. here’s mistake number 2 on my part. i assumed that disk1 was the only important disk for the VDP appliance. so i only snapped disk1…the VDP manual states that you need to turn off independent mode for _all_ of the VDP appliance disks and then create a snapshot…so i couldn’t do a clean rollback. i kept messing with trying to reapply the 5.5 upgrade and eventually got it to take. i was thinking whew disaster averted…

the VDP plugin was visible in the web client. “vdp-configure” showed all services started. however, when i went to connect to the appliance from the web client there were no VDP appliances listed. the drop down list was simply blank. i tried rebooting the appliance and reregistering the appliance with vcenter. no change. i eventually gave up and decided to just get rid of the botched VDP install and start fresh with a clean install of 5.5. i deleted the VDP appliance and then followed the instructions to remove the VDP related plugins: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2038356 and http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1025360.

even after a fresh install of VDP 5.5 the issue persisted. at this point i contacted vmware support. the VDP support guys were stumped because everything looked healthy (which is what i was observing as well). a VDP support person decided the issue must be on the vcenter side of things and transferred me over to vcenter support. after describing the issue to the new support person they decided it would be best to uninstall and reinstall the vsphere web client on the vcenter server. after the web client was uninstalled the old install folder was renamed (c:\programdata\vmware\vsphere web client) and then the product was reinstalled.

i cannot recall if it was necessary to reregister VDP with vcenter once more after the install completed, but the reinstall did resolve the issue.

final advice – i became complacent with doing appliance upgrades via isos because i’ve done quite a few and it’s a simple process. there haven’t been any issues up until this. VDP is a different kind of animal and deserves full attention and thorough reading of the documentation.

vdp 5.5 addendum (6/2/2016):
i still had vdp 5.5.x running at a DR site and was surprised that i could not get to the vdp-configure URL today. i could ping the appliance IP fine but i could not access the page no matter what browser i tried – chrome, IE, firefox. an appliance reboot did not help matters. i eventually found out this was due to the popular web browsers removing support for DSA ciphers. the strange thing in this case is usually that problem is fairly obvious with other products, but in this case the reported errors made it seem like a connectivity issue or that a web service was not running.
source: https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2111900