i’ve personally only had to go through the adprep process once in 2009 (so far). i figured it would be good to notate the process for future reference though. it came up again recently for a different AD domain…

for introducing a windows 2008 DC:
run the following from the windows 2008 install media on the schema master
d:\sources\adprep\adprep.exe /forestprep

then on the infrastructure master run
adprep /domainprep

notes:
you may need to run the 32-bit version of adprep. also i’m assuming functional levels are at most current (which would be 2003 in this case). when operating at a 2000 functional level extra steps might be necessary. there is another adprep step for preparing the domain for read-only DCs, it’s “adprep /rodcprep”. we had no plans of introducing RODCs so we did not do this step. you’ll get an error in dcdiag for not doing the RODC prep, but it appears that it is okay to ignore it.

the process will be the same for introducing a windows 2008 r2 DC however adprep will be in the d:\support folder on the install media.

also in-place upgrades of domain controllers are supportable by microsoft, but best practices dictates setting up a new DC with the latest version of windows server and decommissioning the older DC. some people say that you should transfer FSMO roles prior to doing an in-place upgrade, however, that doesn’t appear to be necessary.

the five FSMO (flexible single master operation) roles:
PDC emulator
RID (relative ID) master
infrastructure master
schema master
domain naming master

sources:
http://www.petri.co.il/windows-server-2008-adprep.htm
http://www.petri.co.il/prepare-for-server-2008-r2-domain-controller.htm

update 7/23/2014:
windows 2012 domain controllers do not require adprep to be ran manually. in fact, both adprep & dcpromo are taken care of automatically when adding the AD DS role to a windows 2012 system.
further details: http://kpytko.pl/2012/09/07/adding-first-windows-server-2012-domain-controller-within-windows-200320082008r2-network/

ben mentioned to me about 2 weeks ago that when installing update rollups for exchange 2007 you should start with the CAS servers first. i found an MS article that said the same thing.

so i installed the latest rollup on the CAS, hub transport, and then finally the mailbox servers. i ran the updates from an administrator-level command line. the updates don’t really apply in a few minutes. i think in just about every instance the update took from 10-15 minutes to apply per server (at least). i rebooted the servers after applying the update, however, i believe the only servers that actually prompted me for a reboot were the mailbox servers.

source:
http://technet.microsoft.com/en-us/library/ee221147(EXCHG.80).aspx

it’s necessary to temporarily prevent a compromised exchange account from sending out spam. you could of course disable the mailbox, but then the mailbox would be marked for deletion and would be purged in 30 days. so if you forgot to reconnect the mailbox before the 30 days you’d probably have to restore the mailbox from a backup.

an easier way to accomplish this is to alter the storage limits on the user’s mailbox. change “prohibit send at” to 0KB.

source:
http://social.technet.microsoft.com/Forums/en-US/exchangesvradminlegacy/thread/2bae33f6-4039-462f-b86d-ce873727a1a3

http://technet.microsoft.com/en-us/sysinternals/bb897553

psexec example:
psexec \\remote-computername  ipconfig /all

pretty neat program

to hook up a md1200 DAS to a r510 a PERC h800 adapter card is required. initially, we were shipped a h810 adapter card which happened to be a low-profile pcie card and thus would not fit correctly in the r510 (which requires standard sized cards)

the md1200 is connected via mini-SAS cables and the virtual drive can probably be configured from the PERC configuration utility (ctrl-R) during the boot process. i chose the easier route of using openmanage (OMSA) to configure the virtual drive. just open up OMSA and go to storage->the correct PERC (H800 in this case)->virtual disks, then begin the create virtual disk wizard. i preferred the advanced wizard over the express one.

initially, the disks were not visible from the wizard and i wanted to install the latest PERC driver to eliminate that as being the issue. that’s when things went downhill. right after the driver install i could no longer boot into windows, only the windows recovery console. the r510 also had a PERC h700 that controlled the RAID container that housed the windows OS. the h700 and h800 use the same set of drivers…so when i installed the latest driver it applied to both PERCs. i messed around with trying to fix the issue for about an hour before contacting dell support. finally got to a last known good configuration thanks to dell support. basically, you need to continuously press F8 right when the RAID initialization shows up in the boot process. keep pressing F8 through the DRAC setup dialog and you’ll eventually get to the windows boot options. before contacting support i tried this repeatedly because i hoped to get into windows safe mode and remove the offending driver, but i had no luck.

the functional driver version for the perc 700: 5.2.220.64

anyways, that’s a bit off track there but important to notate nonetheless…

the _actual_ problem of why the disks weren’t visible is because i hadn’t firmly connected the mini-SAS cables. the mini-SAS connectors can appear to be firmly connected but a slight jostling will make the cable fall out of the slot. the proper way to connect the mini-SAS cables is to insert the connector all the way then give it one last push until you hear a clicking sound. then the cable is correctly connected. so my fault…but at least it was a simple solution.

we experienced this issue in 2010, but i never got around to fully documenting the cause and solution.

after a planned ESX host reboot, the host would not reconnect to vcenter (no matter how much time went by).

/var/log/messages shows:
Sep 22 10:26:05 esx14 xinetd[3078]: START: vmware-authd pid=25229
from=127.0.0.1
Sep 22 10:26:05 esx14 xinetd[3078]: EXIT: vmware-authd status=255
pid=25229 duration=0(sec)
Sep 22 10:26:08 esx14 xinetd[3078]: START: vmware-authd pid=25281
from=127.0.0.1
Sep 22 10:26:08 esx14 xinetd[3078]: EXIT: vmware-authd status=255
pid=25281 duration=0(sec)
Sep 22 10:26:12 esx14 xinetd[3078]: START: vmware-authd pid=25331
from=127.0.0.1
Sep 22 10:26:12 esx14 xinetd[3078]: EXIT: vmware-authd status=255
pid=25331 duration=0(sec)

vmware support determined that the problem was related to iscsi vmkernel ports that were recently removed in vcenter. despite being removed in vcenter, the ports were still listed as bound to this host’s iscsi adapter.

commands to list and remove:
esxcli swiscsi nic list -d vmhba#
esxcli swiscsi nic remove -n port_name -d vmhba#

i seem to forget how to do this every time i need to actually do it…

if you have an expired cert on a windows terminal server then restarting the “Terminal Services Configuration” service should auto-generate a new cert. opening up a remote Certificates MMC should allow you to export the newly generated Remote Desktop certificate. these auto-generated certs seem to only be good for six months at a time.

source:
http://social.technet.microsoft.com/Forums/en-US/winserverTS/thread/1b528a7b-882a-4dc0-bb63-e36968cc284d/

according to cisco docs, g.711 recorded audio takes up 8KB per second of audio. so a full minute of recorded audio should take up 480K of disk space. approximately 42MB of data should equate to approx. 87-88 minutes of recorded audio.

the cisco defaults and general recommendations are to allow 20-30 minutes of voice messages per user

from a machine running the 32-bit version of the management tools plus a local install of outlook 2007:
Export-Mailbox -Identity <username> -PSTFolderPath <example: C:\PST>
(run the Exchange Management Shell as Administrator)

the domain user logged in must have the appropriate exchange privileges and full access permissions to the mailbox being exported.

source:
http://blogs.technet.com/b/exchange/archive/2007/04/13/3401913.aspx