Stuff and Things

Browsing Posts published by authorX

If you are trying to expand a system partition on windows 2003 Server, you are going to find, that there is no on-board solution to achieve this.

Even Diskpart will tell you, that it will not support this function.

But there is help from DELL
They created a simple and small command line utility, which can do exactly that.
Download the tool here:

First of all, you will have to add more disk space to the System you are trying to expand.

In case of a virtual machine, simply edit the disk size in your virtualization management software.

In case of a RAID Disk, you could add more disks to the RAID, or replace the existing disks with larger ones, one by one. (e.g. replace one, wait for rebuild, replace the next one and so on.)

In the end, use your RAID Manager software to expand the RAID Partition .

Once this is done, fire up your server and open Computer Management. Check Disk Manager to see if the system can see the additional space (if you can’t see it, use the “rescan disks” command before you look further)

If you can see the free space, you are ready for the expand

Open a command prompt and run the extpart.exe command.

Enter your System partitions drive letter when asked (e.g. c:)

Then enter the amount by which you want to extend the partition in MB

So if you have a 15GB partition and 10GB additional space, enter 10240 (10*1024MB)

Hit enter and your partition will be extended.

This will work for non-system partitions too by the way.

Exchange, when first installed, uses FQDN’s as Access URLs by default.

This means internal Mail clients will use something like exserver1.contoso.internal, while external clients will need to use

This will mean, that you will either have to configure multiple ip addresses on you exchange server and then configure separate SSL Certificates to avoid errors, or live with the certification errors.

But there is a simpler way, and it allows you to use a single SSL Certificate internally as well as externally.

Here’s how. Open Exchange Management Shell and run the following commands. Make a note of the values shown and save them as a backup.

Get-OutlookAnywhere | Select Server,Identity,ExternalHostname,Internalhostname

Get-OwaVirtualDirectory | Select Identity,ExternalURL,InternalURL | fl

Get-ECPVirtualDirectory | select Identity,ExternalURL,InternalURL| fl

Get-ActiveSyncVirtualDirectory | Select Identity,InternalUrl,ExternalUrl| fl

Get-WebServicesVirtualDirectory | Select Identity,ExternalURL,InternalURL | fl

Get-OabVirtualDirectory | Select Identity,InternalURL,ExternalURL| fl

Get-ClientAccessServer | Select Name, Identity,AutoDiscoverServiceInternalURI | fl

Then start setting the Values to a common URL. Here we are going to use

Note the Get-xxx | before the Set-xxx command. This is so if you have multiple servers in your Organization, the Values are set for all servers automatically.

If you want to avoid this, remove the Get-xxx | in front of the commands, and use the Identity value to specify which server to configure. (just enter the command without the get-xxx and you will be asked for the identity)

Get-OutlookAnywhere | Set-OutlookAnywhere -ExternalHostname -InternalHostname -ExternalClientsRequireSsl $true -InternalClientsRequireSsl $true -DefaultAuthenticationMethod NTLM

Get-OwaVirtualDirectory | Set-OwaVirtualDirectory -ExternalUrl -InternalUrl

Get-EcpVirtualDirectory | Set-EcpVirtualDirectory -ExternalUrl -InternalUrl

Get-ActiveSyncVirtualDirectory | Set-ActiveSyncVirtualDirectory -ExternalUrl -InternalUrl

Get-WebServicesVirtualDirectory | Set-WebServicesVirtualDirectory -ExternalUrl -InternalUrl

Get-OabVirtualDirectory | Set-OabVirtualDirectory -ExternalUrl -InternalUrl

Then set the SCP Records straight. These are the records in Active Directory, that the client searches for when autodiscovery is attempted internally.

Get-ClientAccessServer | Set-ClientAccessServer -AutoDiscoverServiceInternalUri

To make sure all settings have been applied, specifically the Autodiscovery URLs, start the following command in an elevated command prompt on the CAS(right click cmd.exe and select “run as administrator”)

iisreset /noforce

Now that we have set the Access URLs, we need to make sure that the internal clients can actually resolve and are pointed to a CAS Server.

To enable this, head over to your DNS Server. In case your internal and external domains are the same, you will simply need to add an A Record in your Zone pointing to the ip of your cas server.

If your internal and external domains are not the same, e.g. externally and contoso.internal internally, add a new zone to your DNS server and name it

Then add the record in there.

Now all that is left is to install an SSL Certificate that contains as a value. I’d suggest a wildcard certificate with the name *

Now that we made sure the internal clients can actually resolve, we can now start to configure our outlook clients. Should they already be configured, open the account settings, and click on “Repair”. Autodiscovery will then repair the account and point to the right places.

To make sure or check the connections outlook makes, simply press the Ctrl Key while right clicking on the Outlook icon in your Taksbar, and select “Connection status”. Should one of the connections not contain the new name, then you will need to revisit the above commands and make sure you set all the URLs correctly.

Extending a local Xenserver storage repository can be a bit daunting, especially when dealing with GPT Partition tables, which for example Xenserver 6.0 uses by default.

Preflight Check

  • First of all, you will need to provide Xenserver with actual, additional storage space. If you are using lets say a HP Proliant Server with a RAID configuration, add some more disks, and use the ACU (Array controller Utility) to extend the array with the new disks. Or use any other tool your Storage provides to extend the space.

  • Only perform the steps in this article, if you have a good backup of your host, your vms and your pool metadata. While these commands should be perfectly safe to use, in rare cases, data loss could occur.

    >>> hint: xe host-backup; xe pool-dump-database

  • Shutdown all Virtual machines that reside on the local storage. While I’m not sure it matters, I would advice it. 

  • To find out whether you are having an installation with a GPT Partition table, run this command in the Xenservers local console:

    fdisk -l /dev/sda

    If you see an error like this in the output, skip this section and check the GPT section:

    WARNING: GPT (GUID Partition Table) detected on ‘/dev/sda’! The util fdisk doesn’t support GPT. Use GNU Parted.

    This command will also show you, whether the Dom0 can actually see the extended space as the command should also give out the total size of the device, like this:

    Disk /dev/sda: 899.8 GB, 899898718208 bytes

    If you do not see the full extended size here, check that the storage extend has actually worked and completed, reboot your Xenserver and check again.


Enough talk, lets get to the interesting part.

Here is how you can extend when using ext filesystem:

Head over to the console of your xenserver (if in a pool, preferably use the masters console)

type the following commands:

xe sr-list

the output looks something like this:

uuid ( RO) : e42bd27e-53f2-c2d1-bd2a-f0bb9c391a0e
name-label ( RW): Removable storage
name-description ( RW):
host ( RO): XEN1
type ( RO): udev
content-type ( RO): disk


uuid ( RO) : 8b17697e-0329-be9d-404d-3f739350826b
name-label ( RW): Local storage
name-description ( RW):
host ( RO): XEN1
type ( RO): lvm
content-type ( RO): user


copy the uuid of the storage with the name-label of “Local storage” (in this example, it would be 8b17697e-0329-be9d-404d-3f739350826b)

type the command:

pvscan | grep “<the uuid you noted in the previous step>“

(e.g. pvscan | grep 8b17697e-0329-be9d-404d-3f739350826b)

The output looks like this:

PV /dev/sda3 VG VG_XenStorage-8b17697e-0329-be9d-404d-3f739350826b lvm2 [ 550.7 GB / 3.0 MiB free]

copy the device name (eg: /dev/sd3 )

run this command:

echo 1 > /sys/block/<the device name you copied from the previous step>/device/rescan

(e.g. echo 1 > /sys/block/sda3/device/rescan)

run this command:

pvresize <the device name from the previous step again>

(e.g. pvresize /dev/sda3)


xe sr-scan uuid=<storage uuid you copied in the first step>

(e.g. xe sr-scan uuid=8b17697e-0329-be9d-404d-3f739350826b)

Now go back to the Xencenter and check whether the storage is indeed seeing the free space. You might have to also hit “rescan” in the storage tab on the local storage in Xencenter for it to reflect the changes.

If it does not work, give your Xenserver a reboot just for good measure, and check again.

Also, the steps outlined in this article might be working for you:


If all that fails, chances are, you are using a GPT Partition table on your storage. This makes things a bit more complicated and can lead to possible data loss.

Note that under normal conditions, running these commands will indeed PRESERVER your data.
Make sure you actually followed the pre-flight check to see if you are using a GPT partition or not.

Lets dig in:

use this to check for the partition details of you device:

sgdisk -p /dev/sda

The output would look something like this:

Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 1757614684 sectors, 838.1 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 030E4CA7-CFCF-42BD-96C1-446C242450C4
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 1171743802
Partitions will be aligned on 2048-sector boundaries
Total free space is 6042 sectors (3.0 MiB)

Number Start (sector) End (sector) Size Code Name
1 2048 8388641 4.0 GiB 0700
2 8390656 16777249 4.0 GiB 0700
3 16779264 1171743802 550.7 GiB 8E00


Here you can see that currently, the last usable sector is: 1171743802
While here, also note the Start sector of the partition to extend, in this example: 16779264

Also, you will see that the free space is not reflecting the extended space.

To rectify this, we have to force the GPT Partition to extend to the last sector of the disk.

We use gdisk to do that.

Type this:

gdisk /dev/sda

type the letter x and hit enter, then type the letter e and hit enter again. type the letter w and confirm using the letter y, again hit enter

This will now expand the Partition up to the end of the disk device.

we now run the command from the previous step again

sgdisk -p /dev/sda

The output should now have changed:

Disk /dev/sda: 1757614684 sectors, 838.1 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 030E4CA7-CFCF-42BD-96C1-446C242450C4
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is
Partitions will be aligned on 2048-sector boundaries
Total free space is 6042 sectors (3.0 MiB)

Number Start (sector) End (sector) Size Code Name
1 2048 8388641 4.0 GiB 0700
2 8390656 16777249 4.0 GiB 0700
3 16779264 1757614650 830.1 GiB 0700 Linux/Windows data


Note that before, the last usable sector was 1171743802, and now is 1757614650

This confirms, the partition table was indeed expanded.

That was only half the rent though, we now need to delete the actual partition and recreate it using its startsector and the last usable sector as the end sector.

Note that under normal conditions, running these commands will indeed PRESERVER your data.
Make sure you actually followed the pre-flight check to see if you are using a GPT partition or not.

remember that device name we wrote down earlier? In this example, it was /dev/sda3 (and usually is the default on the Xenserver)

We now use the command:

gdisk /dev/sda

Then enter the letter d and hit enter, enter the number 3 (corresponds to the device id (/dev/sda3) and hit enter.

type the letter n and hit enter, type the number 3 and hit enter, paste the Start sector number (from the previous step, in this example: 16779264), hit enter, paste the End Sector number (from previous step, in this example: 1757614650)

If the proposed default value of the start sector is off by only very little, you can simply confirm all the defaults, as the utility will automatically realign the partition and reflect the correct value)

Confirm the default for the next step about the HEX code by hitting enter. and finish the wizard. After that, type the letter w to actually apply the changes.

After this done, a reboot of the Xenserver will usually be enough to make Xenserver realize it has more space. If after the reboot, you can still not see the storage in Xencenter, simply rescan the storage using Xencenter, and you should be golden.

If you can not reboot the host, try running the command

xe-toolstack-restart and see if that worked. Haven’t tried this myself, but think this could also work instead of a restart.

Good Luck everyone!



What you need to complete these instructions is the following:

  1. A bootable Windows based live CD or
  2. A bootable Linux Live CD with NTFS Support

    Examples: Hiren’s Boot CD, BartPE, UltimateBootCD

  3. Boot your computer using the live CD
  4. Access your Windows Partition and navigate to <Driveletter>:\windows\system32
  5. Rename the file utilman.exe to something else (e.g. utilman.exeold)
  6. Create a copy of the file cmd.exe in the same location and rename that to utilman.exe
  7. Reboot your computer back into windows. (remove the live cd)
  8. On your login screen you should find an icon for “Accessibility options”. Click on that and a black command window will open

If you want to reset the password for a user called User1, you will now have to type the following command:

net user User1 <password>
(replace <password> with the new password you want to set)

If you want to add User1 to the administrators group, use the following command:

net localgroup Administrators User1 /add

Then reboot your computer. You should now be able to logon using User1 and the new password you set.

This works because a click on the Accessibility options would usually open the file utilman.exe. Since we replaced that with cmd.exe, it will instead open a command prompt. This command prompt will be running under the System account which means it has all the rights it needs to reset users and passwords.

As alway, if you do such a thing, make sure you are authorized to run these steps on the machine. If you use this to get Administrative rights on your office computer, you could be breaking IT rules and could be fired.

Before you begin, generate a Key file Pair using a tool like Puttygen!!

Add a User

useradd -c “<name.lastname>” -s /bin/bash -m <username>

openssl rand -base64 6 | tee -a ~<username>/.password | passwd –stdin <username>

This creates the user and saves a random Password for him

copy the public key file to the user’s home directory and and set the permissons

mkdir ~<username>/.ssh

chmod 700 ~<username>/.ssh

cp <rsa public key file> ~<username>/.ssh/authorized_keys

chmod 600 ~<username>/.ssh/authorized_keys

chown -R <username>:users ~<username>/.ssh

This should be working in most linux distros.

Make sure ssh is configured properly (/etc/ssh/sshd_config)

Also check the authorized_keys content with VI and make sure that the key itself is all on one line.

So it would look something like:

ssh-rsa <the key in one line>

When you import an OVA into a Hypervisor such as Xenserver, the Disk ID’s might be changed by the importer.

However, the fstab file is not updated to reflect those changes.

So if your machine is not booting after importing it, it might help to check the following:

First, run :   ls /dev/disk/by-id

This will give you the Id’s of the Disks as they are currently.

Then open fstab:  vi /etc/fstab

Check the first three entries.

They will look something like this:    /dev/disk/ata-xxxxxx_xxxx_xx    /        xxxx           xxx

Mostly you will find that the output of the first command gives you different names for the disks.

simply edit the fstab file to reflect the new id’s and reboot.

This should get your machine back into working order

Installing a KMS Server seems daunting, but actually is pretty easy.

Here’s how to do it:

1. On the machine that you want to serve as a KMS Server, install the KMS Key you get from your Volume licensing Portal.

– Open a command prompt and use this command

c:\windows\system32\slmgr.vbs /ipk xxxx-xxxxx-xxxx-xxxxx-xxxx

Replace the xxxx-xxxxx-xxxx-xxxx-xxxx with your actual KMS License Key.

2. Restart the licensing service (just for good measure)

net stop sppsvc && net start sppsvc

3. Force activation using

c:\windows\system32\slmgr.vbs /ato

After successfull activiation, KMS should be up and running.

4. Check for the necessary DNS Records that will have been created by this new KMS Server using this command:

nslookup -type=srv _vlmcs._tcp

This should then reply with all your KMS Servers in your Organisation.

If you dont get a response, try this:

c:\windows\system32\slmgr.vbs /sdns

This will instruct the KMS to resend the DNS entries

If you find that there are other KMS Hosts listed, check if they are still in use and if not, remove them by looking at the end of this article

To display information about the KMS Server use this command on the KMS Server:

cscript c:\windows\system32\slmgr.vbs /dlv

(to display office kms infos too, add ” all” at the end)

The Client Side

If your clients have previously used other methods of activation (e.g a MAK Key), you first will have to reset the Product Key to one of the microsoft provided rearm Keys. You can find a list of these on this other great article about this issue:

To reset the product key, use this command:

c:\windows\system32\slmgr.vbs /ipk xxxx-xxxx-xxxx-xxxx-xxxx

Again, replace xxxx-xxxx-xxxx-xxxx-xxxx with the Key you found in the above link.

Then rearm the system

c:\windows\system32\slmgr.vbs /rearm

Reboot the system.

After reboot, if you want to force activation (e.g. to force the KMS count to go up), use this command:

c:\windows\system32\slmgr.vbs /ato

For the first 25 Clients you try to activate, you will get an error about the license count not being high enough. This is normal and will go away once you try to activate the 26th client.

Office and KMS

To activate Office Clients, you will have to download and install the Microsoft Office 2010 KMS Host License Pack here

During install, you can provide the office KMS Key. After installing, again configure your Office Clients with the Rearm Key from the link above.

You can do this by opening office, opening the File Tab, go to Help and then select “Change Product Key”.

After the product Key is changed, you have to again rearm the office installation by using this command:

ospp.vbs /act

To remove KMS from a Server use this:

cscript %windir%\system32\slmgr.vbs /upk”

Then install the new -non KMS License Key using this:

cscript %windir%\system32\slmgr.vbs /IPK [KMS client Setup Key]”

And at last, activate the machine again with this:

cscript %windir%\system32\slmgr.vbs /ato”

KMS will now be deactivated. Don’t forget to remove the no longer needed DNS SRV Records from the DNS server. 

Usefull Links and sources:

Microsoft Office 2010 KMS Host License Pack

Ivan’s Blog

Volume activation Tips and Tricks for Office 2010

Manually configure KMS DNS Records

If you regularely use the Snapshot feature of Xenserver, or, like us, run an external backup tool (Alike by Quorumsoft) that uses Snapshots, you might sooner or later run into a problem, where Xenserver tells you that there is no more free disk space on the storage, when in fact there is ample space left.

This happens because the space used by the snapshots is not actually freed up until the storage is rescanned.

Since I got tired of doing this manually every time the storage “ran full”, I found this little tip to have Xenserver scan its Storage every 30 seconds.

Unfortunately, the interval of 30 seconds can not be changed, and might lead to performance problem on larger installations.

However, so far I have seen no negative repercussions since having this activated.

So here is how to do it.

In your xenserver console, first run:  XE SR-LIST

This will show you alle the Storages configured on your host/pool.

Copy the UUID of the Storage you want to autoscan and then enter this command:

xe sr-param-set uuid=<UUID you copied above> other-config:auto-scan=true

That’s it. Now your problems with the ghost data should be solved.


Configuring SQL Mirroring isn’t that hard. That is, until you need to set it up with the SQL Servers in different Domains. Or you SQL Servers do not use Domain Accounts to run their services Also needed if the services run under local system account or network.

In that case you will need to use Certificate Authentication on your Endpoints.

This requires you to set up certificates on your SQL Servers, transport them to the other Hosts, import them and assign them to users which then will need Access to your Endpoints.

All the information needed for this is available online, but I wasn’t able to find one single page that detailed the complete process.

I tried to use Query commands where I know them or it is easier using them.

So here you go:


 On each Host involved, (Primary Server, Mirroring Partner and Witness Server) you will first need to create an endpoint that uses certificate authentication. Replace <hostnameA> with the name of the host you are working on (you can name it whatever you want, but for me it makes sense to call them like its host)

1. Generate a master key:


2. Create the certificate

You can select the expiry date of the certificate by changing EXPIRY_DATE

USE master;
WITH SUBJECT = ‘<HostnameA> certificate for database mirroring’,
EXPIRY_DATE = ’11/30/2016′;

3. Create the endpoint and assign it the certificate

If you run multiple instances of SQL on one host and mirror both the instances, you will have to create endpoints for each of them. Also, you will need to use another port for additional endpoints. Do this by changing the LISTENER_PORT value.

CREATE ENDPOINT Endpoint_<HostnameA>

4 Backup the certificate so you can move it to the other hosts

BACKUP CERTIFICATE <hostnameA>_cert TO FILE = ‘c:\<hostnameA>_cert.cer’;


On each host you will have to create a database login and a database user for the other hosts and then assign it the other hosts certificate.

<hostnameA> again stands for the host you are working on, <hostnameB> is the foreign host.

1. Create a database login for the foreign host

USE master;
CREATE LOGIN <hostnameB>_login WITH PASSWORD = ‘<strongPassword>’;

2. Create  a login user for the foreign host

USE master;
CREATE USER <hostnameB>_user FOR LOGIN <hostnameB>_login

3. Import the foreign host’s certificate and assign it to the user

Requires that you have already copied the certificates we exported from the other hosts to this host.

USE master;
AUTHORIZATION <hostnameB>_user
FROM FILE = ‘C:\<hostnameB_cert.cer>’;

4. Assign access rights to the local endpoint

USE master;
GRANT CONNECT ON ENDPOINT::Endpoint_<hostnameA> TO <hostnameB>_login


After the endpoints are configured, let us start mirroring a database

1. Create a full backup of the database on your source host

USE <databaseName>;
BACKUP DATABASE <databaseName>
TO DISK = ‘c:\<databaseName>.Bak’
MEDIANAME = ‘<Medianame>’,
NAME = ‘Full Backup of <databaseName>’;

2. Copy the backup over to your mirroring partner

3. Restore the database on your mirroring partner

  • Use the exact same database Name
  • Restore the database using the NORECOVERY option

FROM DISK = ‘c:\<databaseName>.bak’

4. Go back to your source host and take a transaction log backup of the database

USE <databaseName>;
TO DISK = ‘c:\<databaseName>.trn’
MEDIANAME = ‘<Medianame>’,
NAME = ‘Log Backup of <databaseName>’;

5. Copy the transaction log over to your mirroring partner

6. Restore the transaction log on your mirroring partner

again, use the NORECOVERY option

RESTORE LOG <databaseName>
FROM DISK = ‘c:\<databaseName>.trn’

7. Go back to your source host and right click your database in the SQL management console. Select TASKS –> Mirroring.

Here, run through the wizard and select your source server, your mirroring partner and your witness server if needed. After the wizare finishes you will be asked if you want to start the mirroring. If all went right, the status of the source database will change to (Primary, Synchronized) and your mirror partner database will have a status of (Mirror, Synchronized).

If you receive an error about one of the involved hosts not being able to connect to TCP://, it wil most probably be from incorrectly configured endpoints.

Make sure you create certificate on ALL hosts, import ALL the certificates to each other host and create users for ALL other host on EACH host involved.

Just to make it foolproof, see this:


Source SQL Server:

  • Create a certificate
  • Create endpoint that uses that certificate
  • export certificate
  • Import certificates from mirroring SQL server and witness SQL server
  • Create logins for mirroring SQL server and witness SQL server

Mirroring SQL Server:

  • Create a certificate
  • Create endpoint that uses that certificate
  • export certificate
  • Import certificates from source SQL server and witness SQL server
  • Create logins for source SQL server and witness SQL server

Witness SQL Server:

  • Create a certificate
  • Create endpoint that uses that certificate
  • export certificate
  • Import certificates from mirroring SQL server and source SQL server
  • Create Logins for mirroring SQL server and source SQL server


Some other Handy Commands

Remove mirroring from an already mirrored database


Show configured endpoints on an instance

SELECT name, role_desc, state_desc FROM sys.database_mirroring_endpoints

Drop an already existing endpoint so you can recreate it in case something went wrong

DROP Endpoint <EndpointName>