to set up DHCP failover you’ll need the win8/win2012 version of RSAT. failover can then be configured via specific scopes or the entire IPv4 set of scopes by right-clicking in the MMC and choosing “Configure Failover”. if you have custom scope options they will cause a failure when setting up the failover relationship. this caused no small headache for me. to resolve this you’ll need to track down the custom options by going to to “Define Vendor Classes…” and “Set Predefined Options…” on the primary server and then creating the custom options on the secondary server. the options must match exactly.

i set up the failover relationship in Hot Standby Mode since that was the recommendation for DHCP servers hosted at different sites.

i left Enable Message Authentication enabled and set up a Shared Secret. i left State Swithover Interval disabled for the time being. if this setting is enabled it will allow for automatic failover to the partner server. for instance, if DHCP1 is in a partner down state for 60 minutes then DHCP services will automatically failover to DHCP2. without this setting enabled a manual failover will have to occur by clicking on the Change to partner down button (the partner has to actually be unavailable to click this button). right-click on IPv4 and choose Properties->Failover->Edit to modify the existing failover relationship.

further info:
http://blog.rolpdog.com/2012/11/dhcp-failover-breaks-with-custom-options.html
http://blog.ittoby.com/2013/05/windows-server-2012-superfeature-dhcp.html
http://popravak.wordpress.com/2014/05/31/windows-server-2012-dhcp-failover-with-or-without-custom-dhcp-attributes/

update 12/10/14:
in a hot standby configuration, when deconfiguring failover on a particular scope do not do it from the standby (passive) server. the scope will be deleted from the active server if deconfigured in this manner. instead make sure to deconfigure from the active server only.

first, to allow external Oof messages they’ll have to be allowed globally at:
EMC Organization Configuration->Hub Transport->Remote Domains->Right-click on Default and choose Properties
then choose “Allow external out-of-office messages only”

^the above change did not seem to take effect until both hub transport servers had been rebooted

powershell script:
Get-Mailbox -ResultSize Unlimited | where {$_.ExternalOofOptions -eq “External”} | Set-Mailbox -ExternalOofOptions InternalOnly
Set-Mailbox -Identity user1 -ExternalOofOptions External
Set-Mailbox -Identity user2 -ExternalOofOptions External

to verify settings run:
Get-Mailbox user1 | Select Name, ExternalOofOptions

some info here:
http://exchangepedia.com/blog/2008/07/controlling-oofs.html

finally getting to play around with the vcsa…

default credentials are “root” with the password “vmware”. by default the system will try to retrieve an IP address via DHCP. to configure the network settings from the command line run: /opt/vmware/share/vami/vami_config_net

the appliance can be configured at https://vcsa.mydomain.com:5480 (just an example hostname). once within the web management – vCenter Server->Authentication will allow you to join the appliance to AD. this will also configure the appliance to time sync with AD.

for database i chose embedded and for SSO i chose the following:
SSO deployment type: external (since we have SSO already configured on another vcenter server)
Account with right to register vCenter with the SSO server:
Username: administrator@vsphere.local
Password: <password>

Account that will be assigned as vCenter administrator:
Name: administrator@vsphere.local (i left it as this for simplicity sake, but i imagine this could be an AD user…)

Lookup service location:
URL: https://vcenter.mydomain.com:7444

a cool thing about SSO is that once i logged into either vcenter instance via the vsphere web client i could see the inventories of both vcenter servers.

some info from here:
http://virtualworlduk.co.uk/multiple-vcsas-with-external-sso-linked-on-single-web-client-v5-5/

info here regarding the backup of the postgres database:
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2034505 (not quite a streamlined process yet)

i was trying to remove an old test datastore earlier today and no matter what i tried was unable to. i verified there were no remaining vms or templates on the datastore. i manually deleted any folders i could (i could not remove the vmkdump folder). i tried unmounting first then deleting. i could not even unmount the datastore. i tried the same tactics via the command line with no luck.

i found the following command from a blog (source below):
esxcli system coredump file remove –force

that removed the in use dumpfile and after a reboot i was able to remove the datastore

source:
http://www.virten.net/2014/02/cannot-remove-datastore-because-file-system-is-busy/

windows server 2012 introduces a failover architecture for DHCP so recently i was looking into migrating off of our 2008 core DHCP server to 2012 r2 core. i did the migration about 2 weeks ago and it was simple and mostly painless except for one unforeseen hiccup (that was difficult to troubleshoot).

first, i needed a current copy of the production DHCP database. there’s a ton of ways to accomplish this…i fell back on using:
netsh dhcp server export c:\dhcp_backup.txt all
netsh dhcp server import c:\dhcp_backup.txt all
source: http://community.spiceworks.com/how_to/show/23549-exporting-and-importing-dhcp-database-on-windows-server

you can also do backup/restore operations directly from the DHCP mmc snap-in. the default DHCP database path is c:\windows\system32\dhcp\dhcp.mdb and the backup path is c:\windows\system32\dhcp\backup

and finally powershell cmdlets are available:
Backup-DhcpServer
Export-DhcpServer
Restore-DhcpServer
Import-DhcpServer

i’m not entirely sure what the differences are between some of those cmdlets and at the moment i’m not interested enough to find out.
source: http://technet.microsoft.com/en-us/library/jj590751.aspx

here’s a quick command to disable the windows firewall in server core:
netsh advfirewall set allprofiles state off
source: http://technet.microsoft.com/en-us/library/cc766337(v=ws.10).aspx

after getting a current backup of the production DHCP database i then proceeded to unauthorize the production DHCP server and then shut it down. i imported the database to the new 2012 r2 server and then i ran into the hiccup i mentioned earlier. i could not connect to the new DHCP server via the MMC snap-in (even though i could moments before…prior to the cutover). i verified that the DHCP service was running. i even restarted the server…same end result. i looked at PTR records and tried MMCs on other machines. on purpose i was trying to retain two A records for this server in DNS. the reason being was because i didn’t want to break people’s saved MMCs, but it finally got to the point in the troubleshooting process where i needed to try to remove one of the records to see if it resolved the MMC issue. and it did as soon as i removed the A record for “DHCP” and kept only the “DHCP1” A record i was able to immediately connect and authorize the new DHCP server. i don’t think i’ve encountered problems with multiple A records with any other service before, but there’s a first time for everything…

the last item i dealt with was the DHCP security groups. since i installed the DHCP role from the command line i did not get a post-install configuration wizard. this wizard typically set ups the security groups. i was in a hurry to leave so i created the groups manually: DHCP Administrators (R/W access) and DHCP Users (RO access). if i had read more carefully at the time i would have noticed there was a command line option to create the groups…
netsh dhcp add securitygroups

the DHCP service should be restarted after creating the security groups
source: http://technet.microsoft.com/en-us/library/ee941205(v=ws.10).aspx

restart DHCP service from powershell: Restart-Service DhcpServer
authorize DHCP server from powershell: Add-DhcpServerInDC -DnsName <dhcp server hostname> -IPAddress <dhcp server IP address>
source: http://blogs.technet.com/b/teamdhcp/archive/2012/08/31/installing-and-configuring-dhcp-role-on-windows-server-2012.aspx

and finally here’s info for configuring DHCP failover in windows server 2012:
http://technet.microsoft.com/en-us/library/hh831385.aspx

in this instance dell one identity cloud access manager…
powershell script:
import-module MSOnline
$msolcred = get-credential
connect-msolservice -credential $msolcred

Set-MsolDomainAuthentication `
-Authentication federated `
-DomainName federated.mydomain.com `
-ActiveLogOnUri https://proxy.campoc.mydomain.com/CloudAccessManager/RPSTS/WSTrust/Service.svc/trust `
-FederationBrandName “Cloud Access Manager” `
-IssuerUri urn:proxy.campoc.mydomain.com/CloudAccessManager/RPSTS `
-LogOffUri https://proxy.campoc.mydomain.com/CloudAccessManager/RPSTS/WSFed/Default.aspx `
-MetadataExchangeUri https://proxy.campoc.mydomain.com/CloudAccessManager/RPSTS/WSTrust/Service.svc/mex `
-NextSigningCertificate “” `
-PassiveLogOnUri https://proxy.campoc.mydomain.com/CloudAccessManager/RPSTS/WSFed/Default.aspx `
-SigningCertificate “<cert data>”

^note: the signingcertificate string must all fit on one line (no line breaks)

finally, run Get-MsolDomainFederationSettings -DomainName federated.mydomain.com to verify the federation settings.

sources:
http://documents.software.dell.com/book/2602
https://support.software.dell.com/dell-one-identity-cloud-access-manager/release-notes-guides

i received this error message for the very first time today after importing a vendor’s vm files in vcenter. a quick google shed some light on the subject. the error indicates that the vmdk file is in a vmware workstation format that is incompatible with vsphere. to get around this the vmdk file must be converted.

to convert:
SSH into an ESXi host
run vmkfstools -i old.vmdk new.vmdk
path to datastores: /vmfs/volumes/<datastore name>

the process can take a while depending upon how large the vmdk file is.

source:
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1028943

it’s useful to change the default virtual hardware version for new vms because most people probably don’t want version 10 yet. also if you’re on vsphere 5.5 you probably don’t want a new vm starting at version 7 and then going through the process of updating it to version 8 then version 9.

the setting can only be changed from the web client. once logged into the web client go to vcenter->specific cluster->manage->settings->general and change “default vm compatibility” to the desired value. version 9 is esxi 5.1 and later.

source:
https://blogs.vmware.com/vsphere/2013/02/managing-virtual-hardware-versions-during-a-vsphere-upgrade.html

from the ADFS management console it doesn’t appear that there is a method to use a metadata file to update an existing relying party trust. i had to resort to deleting the old trust and recreating a new one with the new metadata file. of course this means that claim rules have to be recreated (which could be a pain).

i figured there must be a better way to do this…and found the related powershell cmdlets.

use Get-AdfsRelyingPartyTrust to retrieve info for all relying party trusts or Get-AdfsRelyingPartyTrust [name/display name] to retrieve info about a specific trust.

to update an existing trust from a federation metadata file use Update-AdfsRelyingPartyTrust -TargetName [name/display name] -MetadataFile [file path]

source:
http://technet.microsoft.com/en-us/library/dn479361.aspx

update 5/1/2014:
just discovered these cmdlets only exist in windows 2012 r2 and not in previous releases 🙁

update 4/30/2014:
confirmed that Update-AdfsRelyingPartyTrust works as expected in 2012 r2