In case you run into slow account setup with Outlook and/or Exchange 2016, which can take up to 10 mins or more, here’s a possible fix. Add the following key to your registry:
It is assumed this is caused by some bug in Outlook/Exchange that causes the system to try a little too hard to obtain a response from the Autodiscover directory on your root domain. If the domain resolves in DNS but does not respond to HTTP queries (i.e. you don’t have an actual server to acknowledge them), this will cause timeout error and Outlook will try repeatedly.
If you wait long enough (11 attempts or so, each taking at least 30 seconds), Outlook will actually give up and move on. But if you don’t like waiting, the reg key above will force Outlook to bypass this particular check and it will continue to the next method. So as a result the process will take a substantially smaller amount of time.
Once you had your drives installed, SSH to your ESXi box (now even easier in vSphere 4.1) and
go to the /dev/disks directory.There, if you perform a ls -l, you’ll see your drives listed:
/dev/disks # ls –l
-rw——- 1 root root 2013265920 Nov 2 22:17 mpx.vmhba32:C0:T0:L0
-rw——- 1 root root 4161536 Nov 2 22:17 mpx.vmhba32:C0:T0:L0:1
-rw——- 1 root root 262127616 Nov 2 22:17 mpx.vmhba32:C0:T0:L0:5
-rw——- 1 root root 262127616 Nov 2 22:17 mpx.vmhba32:C0:T0:L0:6
-rw——- 1 root root 115326976 Nov 2 22:17 mpx.vmhba32:C0:T0:L0:7
-rw——- 1 root root 299876352 Nov 2 22:17 mpx.vmhba32:C0:T0:L0:8
-rw——- 1 root root 1000171331584 Nov 2 22:17 naa.600508b1001c0d5c9380ee1ca76a0e61
-rw——- 1 root root 1000169537536 Nov 2 22:17 naa.600508b1001c0d5c9380ee1ca76a0e61:1
-rw——- 1 root root 1000204886016 Nov 2 22:17 t10.ATA_____ST1000DL0022D9TT153__________W1V0K1R4
-rw——- 1 root root 1000202273280 Nov 2 22:17 t10.ATA_____ST1000DL0022D9TT153__________W1V0K1R4:1
-rw——- 1 root root 1000204886016 Nov 2 22:17 t10.ATA_____WDC_WD10EACS2D00ZJB0__________WD2DWCASJ1866379
-rw——- 1 root root 1000202043392 Nov 2 22:17 t10.ATA_____WDC_WD10EACS2D00ZJB0__________WD2DWCASJ1866379:1
Ignore the instances of your drives which show them as VM stores (vm1.*****).
We want to look at the raw devices. Example is: t10.ATA_____ST1000DL0022D9TT153__________W1V0K1R4
Now move to the /vmfs/volumes folder. Here you can see your existing local datastore(s).
If, like me, you had a solitary hard-drive, you’ll just see localdisk01 or whatever you chose to name the local datastore.
Now we are going to use the vmkfstools utility to create our RDM’s. Remember that a RDM is just
another VMDK, but instead of the VMDK pointing to a xxx-flat.vmdk file (which is the actual virtual hard disk),
the VMDK points to our physical device. Being as we still need to create this VMDK file we need to save it somewhere.
Since we just have the one local datastore, we are going to create the RDM VMDK files in it’s root.
The following command creates the RDM VMDK for us:
vmkfstools -z /vmfs/devices/disks//.vmdk
In my personal example below, I am creating an RDM calledrdm_WD2DWCAVU0477582.vmdk and it is being
stored in the location/vmfs/volumes/localdisk01/ I chose the name of the VMDK to match the name of the serial
number of the physical drive (and what is shown in Step 1) to help with troubleshooting in the future when I
get an inevitable drive failure). You can call your RDM’s whatever you wish.
The name of the RAW device (t10.ATA____WDC_WD10EARS2D00Z5B1__________WD2DCAVU0477582 in my example)
you will have noted from Step 1 when you listed all local devices attached to your ESXi host.
You will want to copy the full device name as shown in Step 1 in to the vmkfstools command.
vmkfstools -z /vmfs/devices/disks/t10.ATA_____ST1000DL0022D9TT153
Once you have repeated the steps for all of your local SATA drives, you can navigate to where
you created the RDM’s (in my case /vmfs/volumes/localdisk01) and perform an ls -l *.vmdk to
see the new VMDK’s you have created:
Don’t panic – the xxx-rdmp.vmdk files will reflect the size of the RAW devices they are mapping
to, but rest assured it will be taking no more space than a few bytes on your local disk!
You can now add your RDM’s to an existing VM. vSphere doesn’t recognise this as a true RDM (to a SAN)
so you just browse the local disk datastore for the VMDK files that we created.
Edit the properties of an existing VM and click Add…
Select Use an existing virtual disk and click Next >
Click Browse. You now need to navigate your local datastore and select the VMDK’s that we
created in Step 3).
Once complete you will be shown a confirmation window. Repeat Steps 5 through 7 to add additional
RDM’s to your VM.
You should now see your new Hard Disk’s in your VM and vSphere will correctly identify them as
Mapped Raw LUN.
You can now save your VM configuration. Your VM will now access the RAW SATA drives and be able to
use things like SMART to monitor its health.
NOTE: RDM mapping of drives stops the ability to take snapshots in vSphere Client. In order to snapshot, you must reverse this procedure.
Original post: http://blog.davidwarburton.net/2010/10/25/rdm-mapping-of-local-sata-storage-for-esxi/
Tested with SQL Server 2008 and 2012.
SQL Server might not start from all variety of reasons including permission issues, master database not available or corrupted, service account issues, etc. In this article I will talk about diagnose of failed service start and how to fix %%17051 error.
Diagnostic SQL Server service failed to start
General information are being logged into Event log whereas additional information are being logged into Error Log located by default in DRIVE_LETTER:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Log\ERRORLOG
When SQL Server does not start which you would find out by simply looking into configuration manager
Then first place where you should start looking is the Event Log System category. Find an error generated by Service Control Manager.
Let’s take a look into the Error Log
Mind the row number 13 “SQL Server evaluation period has expired.” Now you have two options. Uninstall your evaluation copy of SQL Server or run Edition Upgrade – you will need to enter your Product Key during upgrade process.
For Edition Upgrade you will need SQL Server setup files. In SQL Server Installation center navigate to Maintenance section and click Edition Upgrade.
Check whether all Setup Support Rules are marked as Passed and click OK.
Again check whether all Rules are marked as Passed or Not applicable and click Next.
In Product Key step change Radio Button to option Enter the product key and type in your key. If you are using a VLK SQL Server version a Product Key will be already entered at this point.
In next steps accept license terms, specify your instance you wish to upgrade, check edition upgrade rules and finally click Upgrade button.
I my case Upgrade and Back button had been gray for a few minutes. When the upgrade process is done you will see similar screen with link to Setup Boostrap Log.
Now you might need to start your SQL Server Services manually.
When you connect to your instance you may check your edition by running script bellow.
Note for SQL Server setup files
Your setup files does not need to be at same Service Pack level as your instance (no need for slipstreaming). Also you can Edition Upgrade from Standard to Enterprise, Developer and/or Business Intelligence and vice versa between all versions.
Using your preferred Telnet client (such as putty), run the below list of commands:
telnet SERVERADDRESS 25
Note: 25 is the port for MX/SMTP
Once connected you will see something similar to the below:
SERVERADDRESS Microsoft ESMTP MAIL Service ready at Wed, 7 Aug 2013 11:30:12 +1000
At this point, type the below 2 commands into the Telnet console:
mail from: email@example.com
You should either see a sent ok output or an error with an SMTP error code.
See below a link for a list error codes:
1. Download VMware-ESXi-5.1.0-799733-depot.zip (or latest version) from MyVMware
2. Copy the ZIP file to host datastore using WinSCP
Note: Enable SSH and Shell from VMware Troubleshooting menu first.
3. Run the below command to perform the update
esxcli software profile update -d depot_location -p profile_name
(eg: esxcli software profile update -d /vmfs/volumes/datastore/VMware-ESXi-5.1.0-799733-depot.zip -p ESXi-5.1.0-799733-standard)
4. Reboot the host
5. Run vmware-v to check the ESXi host version
NOTE: esxcli can only be used to update within the same version of ESXi (e.g. v4.0 to 4.1 or v5.1 to v5.5). Upgrades between versions are best to be run via vCenter or an ESXi Install CD/DVD.
Recently we had an issue with a client’s server where corrupted snapshots of a virtual server caused multiple snapshot files allocating more than 100% disk space to a single virtual server (a domain controller). The virtual server in question was still running but would frequently crash as there was not enough disk space to allow for virtual swap files. The fix (and a last stich effort option we didn’t have to use) is below.
-Error messages stating virtual swap file cannot be created.
-Multiple swap files (e.g.: servername_00001.vmdk, servername_00002.vmdk, etc.) allocating more than 100% disk space
-Datastore with little space available.
-Servers going offline.
-Stuck tasks shown in VMware ESXi SSH (see http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1013003)
Steps to Resolve:
Correcting the snapshots by consolidation
1. Power off the problem VM (or preferably all VMs). If this is not done the VMs continue to use swap space and if you have stuck tasks they can to. If you have stuck tasks reboot the server in full and keep the VMs powered off.
2. Clear ANY space available on the VM. Do not delete or rename any VMDK files or anything else in a VMs directory.
3. Take another snapshot of the problem VM. Ensure to un-tick the options to ‘Snapshot the virtual machine’s memory’ and ‘Quiesce guest file system’. If these are kept ticked the snapshot will use more disk space and cause further complication.
4. Once complete, open Snapshot manager and delete all snapshots. Doing so should consolidate all files and return the VM and the ESXi server to full health. This process may take several hours to complete and it normally gets stuck for most of this time at the 99% mark (as this is when it is actually moving the data).
Note: Do not run the ‘Consolidate’ function at any stage, only the ‘Delete All Snapshots’. Running the consolidate function will again use more disk space than required.
Correcting the VM by VMware Converter
This option should not be your first one. It is possible (if you can get you VM powered on) to use VMware Converter to convert your VM (V2V) to another datastore or server. This can be a complicated process as it either requires another standalone VMware ESXi server or the addition of further internal storage (Normally SAS, SCSI or SATA) to the current ESXi server.
USB Drives cannot be used for this as they are not supported in ESXi for direct datastore usage. The process should be similar to the below:
1. Locate an appropriate disk (for example a 1TB SATA disk).
2. Power off the ESXi Server.
3. Install the SATA disk in a spare SATA slot.
4. Power on the ESXi Server.
5. Do a scan for the new storage.
6. Create a new datastore.
7. Move the affected VM to the new datastore (giving it more disk space).
8. Run the process in Option 1 again.
9. If the Option 1 process does not work, power on the VM and use VMware Converter to V2V back to the original datastore.
Note: The V2V process does not recreate the snapshot files but does create a new Virtual Disk without the previous issues.
Windows SBS comes by standard with 5 CALs built into the system for using all aspects of the server (File, Print, Exchange…) but buying more licenses is different for each system and version.
At the writing of this document, Microsoft no longer produce SBS. SBS 2011 was the last version and whilst you can still get copies of this server off the shelf it is no longer being made.
Licensing for SBS across all versions allows for a maximum of 75 CALs. SBS 2008 and 2011 has an honour system for its CALs much like other modern versions of Windows Server. You must own X number of CALs, either one per machine or per user. This however is not directly affected on the server itself – no changes need be made for the licensing to come into effect.
SBS 2003 however must have a Serial Number entered into its Licensing Tool (Administrative Tools\Licensing) before the CALs come into effect. SBS 2003 licenses can no longer be purchased but SBS 2008 and in some case SBS 2011 CALs are backwards compatible with SBS 2003.
If you wish to buy and install SBS 2003 CALs, contact the Microsoft Activation Line for your country. In most cases they can provide you with an appropriate SBS 2003 Activation Code for your server. Note that as of 14/07/2015 Windows SBS 2003 will be at End of Life and no longer supported.
Further information can be obtained from the below Microsoft PDF, including usable SBS 2003 Serial Numbers (these are able to be used provided you have purchased 2008 or 2011 Equivalent CALs.)
SBS 2011 Licensing FAQ.pdf
From the above document, retrieved 5/02/2014:
“20 CAL Keys 5 CAL Keys
Recently we’ve had the requirement to uninstall an update from a Remote PC. The PC is unresponsive to input from the KB and Mouse so the only other option was running the uninstall from remote. This can be easily done using the below commands, but it can be extended to remotely run any program on a target PC.
To do so, WMIC is used to run a new process on the target PC (node) and powershell is invoked running the command.
Please see the below for examples:
wmic /node:PCNAME process call create “powershell INSERT COMMAND HERE”
Example: Uninstalling a Windows Update from remote:
wmic /node:PCNAME process call create “powershell wusa /uninstall /kb:3097877 /quiet /forcerestart”