No coredump target has been configured. Host core dumps cannot be saved

Configuring ESXi coredump to file instead of partition (2077516)


This article provides steps to configure ESXi to generate coredump as a file on VMFS.
On ESXi\ESX hosts that are upgraded to ESXi 5.x, the core file size is limited to 100 MB. In most cases this is not enough to handle the coredump file size. It is recommended to configure the ESXi host to generate coredumps as a file.


Note: Software iSCSI and Software FCoE are not supported for coredump locations.
To configure ESXi to generate the coredump as a file on VMFS:
  1. Connect to the ESXi host using the SSH.
  2. Run this command to add a new file, used as coredump:esxcli system coredump file add

    -d can be used to specify the vmfs datastore used for the coredump file. If it is not provided, a datastore of sufficient size will be automatically selected.
    -f can be used to specify a file name for the coredump file. If it is not provided, a unique name will be created.For Example:

    esxcli system coredump file add -d VMFS_VOLUME -f test

  3. Run this command to get the list of all dump files that have an access:esxcli system coredump file listYou see output similar to:

    Path                                                                     Active Configured Size
    ———————————————————————— —— ———- ———
    /vmfs/volumes/52b021c3-f6b3da50-4c76-001d0904c5a5/vmkdump/test.dumpfile  false  false      104857600

    Note: If no coredump file has been specified, no output will be displayed from running the command.

  4. Run this command to set the dump file for the host:esxcli system coredump file set -p /vmfs/volumes/DATASTORE_UUID/vmkdump/FILENAME For Example:

    esxcli system coredump file set -p /vmfs/volumes/52b021c3-f6b3da50-4c76-001d0904c5a5/vmkdump/test.dumpfile

  5. Run this command to verify that the dump file is active and configured:esxcli system coredump file listYou see output similar to:

    Path                                                                     Active Configured Size
    ———————————————————————— —— ———- ———
    /vmfs/volumes/52b021c3-f6b3da50-4c76-001d0904c5a5/vmkdump/test.dumpfile  True   True                   104857600

Continue reading

2003 to 2012 no SYSVOL or NETLOGON Shares


Migrating from 2003 to 2012 r2 Domain Controllers and after doing DCPromo, there were no SYSVOL or NETLOGON Shares.  Looked at event viewer on both servers.  This is what I saw.

The File Replication Service has detected that the replica set “DOMAIN SYSTEM VOLUME (SYSVOL SHARE)” is in JRNL_WRAP_ERROR.

Replica root path is : “c:\windows\sysvol\domain”
Replica root volume is : “\\.\C:”
A Replica set hits JRNL_WRAP_ERROR when the record that it is trying to read from the NTFS USN journal is not found. This can occur because of one of the following reasons.


Did some searching on Google and found this.  I have used Burflags before but never fully understood which is which.  I found that this for some reason clicked with me.  So here is it.


“burflags” was for FRS. Windows Server 2012 doesn’t have FRS, so the comparable procedure is described in this lengthy article:

How to force an authoritative/non-authoritative synchronization for DFSR-replicated SYSVOL (like “D4/D2” for FRS)

Note that there are two separate procedures, one for authoritative, the other for non-authoritative.

“You want to force the non-authoritative synchronization of SYSVOL on a domain controller. In the File Replication Service (FRS), this was controlled through the D2 and D4 data values for the Burflags registry values, but these values do not exist for the Distributed File System Replication (DFSR) service. You cannot use the DFS Management snap-in (Dfsmgmt.msc) or the Dfsradmin.exe command-line tool to achieve this. Unlike custom DFSR replicated folders, SYSVOL is intentionally protected from any editing through its management interfaces to prevent accidents.”

[…] the two procedures, like D2 (non-auth) or D4 (auth) …

“If setting the authoritative flag on one DC, you must non-authoritatively synchronize all other DCs in the domain. Otherwise you will see conflicts on DCs, originating from any DCs where you did not set auth/non-auth and restarted the DFSR service. For example, if all logon scripts were accidentally deleted and a manual copy of them was placed back on the PDC Emulator role holder, making that server authoritative and all other servers non-authoritative would guarantee success and prevent conflicts.

If making any DC authoritative, the PDC Emulator as authoritative is preferable, since its SYSVOL contents are usually most up to date.

The use of the authoritative flag is only necessary if you need to force synchronization of all DCs. If only repairing one DC, simply make it non-authoritative and do not touch other servers.

This article is designed with a 2-DC environment in mind, for simplicity of description. If you had more than one affected DC, expand the steps to include ALL of those as well. It also assumes you have the ability to restore data that was deleted, overwritten, damaged, etc. previously if this is a disaster recovery scenario on all DCs in the domain.”


For me I ended up doing this:

I Ran D4 on the 2003 box after running repadmin and it was showing no errors.  After I restarting the service all seemed to be working just fine.  Now I see SYSVOL and NETLOGON shares on the 2012 Server.

I see this on 2003 Event Viewer:

The File Replication Service successfully added the connections shown below to the replica set:



The File Replication Service is no longer preventing the computer “server” from becoming a domain controller. The system volume has been successfully initialized and the Netlogon service has been notified that the system volume is now ready to be shared as SYSVOL.


Mail Delivery Subsystem: Google Apps

The other day I was working on an issue that we could not send email outbound but inbound worked just fine.  Looked to make sure we were not on any RBL.  We are using Google Apps Web Email so it was not a 3rd Party client.

The Error:

Delivery to the following recipient failed permanently:

[email protected]

Technical details of permanent failure:
Google tried to deliver your message, but it was rejected by the server for the recipient domain [].

The error that the other server returned was:
550-5.7.0 Mail relay denied []. Email is being sent from a domain
550-5.7.0 or IP address which isn’t registered in Google Apps account. Please
550-5.7.0 login to your Google Apps account and verify that your sending device
550-5.7.0 IP address has been registered within
550-5.7.0 Google Apps SMTP Relay Settings. For more information, please visit
550 5.7.0 ee9sm485848igb.4 – gsmtp


Postini is no longer working for you and you need to change the outbound gateway in Google Apps.


In Google Apps you need to change the mail routing.

Go to>  Apps > Google Apps > Gmail > Advanced Settings:  Then Find Outbound gateway

Select the Server you see and delete it.
email routing

Dell t420 Install 2008 R2

Trying to install 2008 r2 on Dell T420 and it would not find the drivers for the Dell PERC H710 Controller.

I downloaded the Drivers for it: Microsoft Windows 2008 R2 SP1 64 Bit Driver for Dell PERC H310/H710/H710P/H810/SPERC8 on and it was an EXE which you cant install on win7 or 8 or a 2008 r2 vm

Call support and found that you have to take the SAS-RAID_Driver_XYPYC_WN64_6.803.21.00_A07.exe and change the exe to .zip and get the Payload folder and put it on a thumb drive and load the drivers in the installation prompt.

Really? Get Windows 10… How to get rid of it!


More info on disabling the Windows 10 update notification including a registry hack: Reg Hack


I just did some windows updates on a laptop I am using at the house and got this.



I don’t know if this is only for OEM or for all windows 7/8.x version.  Mine is OEM on this laptop.


Some more info about it.


it comes from update.