Tips & Tricks

Change a Windows Server 2012 Product key?

For those that are just getting started with Windows Server 2012 you may have noticed that you don’t get the option to change the server’s product key on the activation page. This can be a problem if you need to switch to MAK or KMS keys and reactive the server. No worries, the solution is pretty simple.  You can use one of the following 2 options:

Option #1 –

1. Open a Command promtp and run the following :

slmgr.vbs /ipk  <put  your Product key here>

Option #2 – 

1.  On Windows server 2012  -( with your mouse point to the lower-right  hand corner of the screen)  click Search.

2.  Type Slui.exe 0x3

2012b

3.  When the activation screen pops up type in your new Product Key and Activate.

2012c

Advertisements

Message restrictions on your Exchange groups preventing emails to be received?

A common problem I get support tickets on is distribution groups not receiving emails from non-Exchange systems. There can be various reason for this, but the first thing I do is check the mail flow settings for the group to determine if the group is restricted to only authenticated users.

When groups are created in Exchange 2010, the default settings are applied and off you go, ticket closed. What is often overlooked are the mail flow settings for the group. The mail flow settings control who can send to the group, which senders to reject messages from and require that all senders are authenticated. Typically this not an issue if you’re sending emails to the group in Outlook, but if you want to send emails to this group from outside of the Exchange system, you will want to make sure that this is not enabled. When the “require that all senders are authenticated”  is enabled it prevents any users that don’t have valid logon credentials in your organization from sending emails to this group. If you have servers in your environment that need to send emails to an Exchange group, you will want to disable this setting since that server is not authenticating. If the groups were created prior to Exchange 2010, this setting was not enabled by default therefore there were restrictions.

You can disable the setting by 2 ways, through Powershell or the Exchange Management Console (EMC).

To disable the setting in the EMC:

Go to the group properties in the EMC > Mail flow settings > clear the checkbox on “Require that all senders are authenticated”

Mailflow1

To disable the setting in Powershell:

Set-DistributionGroup -Identity <DistributionGroupIdParameter> -RequireSenderAuthenticationEnabled $false

Mailflow2a

Expanding System Drive of a running W2K3 VM using EXTPART

At some point in time a VM will run low on disk space and you’ll need to add more space to it. For VMs running Windows server 2008 this isn’t an issue but anything older, well , you had to use tools such as DiskPart to get the job done. Let’s say the system drive was running low, for W2K3 servers, this was a little bit harder to expand because you needed to shutdown the VM. Depending on what you were running on that VM getting that shutdown approval could take an act of congress to pass. Expanding the system drive on a running W2K3 VM is not impossible though, for I have the solution that could solve those woes.

A few years ago when my company was just getting started on our virtualization infrastructure (VMware of course) I became familiar with a nice little tool that would expand drives on the fly for VM’s running W2K3 or older. This was pretty important considering over 80% of our servers at the time were still on W2K3. What’s this magical tool that can save us admins from having to shutdown a VM because the users hoarded all the space?

Dell’s EXTPART. I will tell you that there is no guarantees with this and use at your risk. Since I’m a daring person , well honestly, just don’t want to go asking to shutdown the server, I’ve used this tool. I have used it quite often too. I’m still alive, the servers survived, and half the time they didn’t even know they were low on space because I proactively fixed the problem.

Now, this isn’t the magical tool that fixes everything because it does have some caveats. For instance, you can only expand system drives on while running if the VM was not P2V’d. If the VM’s were built from scratch or from a template this tool works great but if your VM was P2V’d you need to reboot into safe mode to expand the system drive. Expanding non system drives while running is perfectly fine on P2V’d VMs using EXTPART.

To use this EXTPART do the following:

  1. To use EXTPART to expand a drive you will first need to download the tool and save it to a location on the VM. The tool can be found here
  2. In vSphere, go to the settings of your VM and increase the Hard disk that you want to expand. If it’s the system drive then most likely you will want Hard disk1.
  3. EXTPART_1

  4. Now go to your VM, open a Command Prompt and navigate to the directory where you saved the download.
  5. Once you are in the file directory of EXTPART, run the extpart.exe file
  6. You will be prompted to type in the Volume or Drive that you want to expand, type in C:
  7. After putting the volume it will display the details of the drive, such as volume and partition size, and ask how much you want to expand the drive. At this point enter in the size (MB) that you want to expand the drive by. This is the amt you are increasing the drive with not the total size of the drive.
  8. EXTPART_2

  9. Once complete press enter and the size of the increased volume will be displayed.
  10. If this fails with an error that “the disk is not accessible” then most likely the VM was P2V’d and you will need to reboot the VM into safe mode. Once booted into safe mode start at step 3 again.

So there you have it, an expanded drive on a running W2K3 VM. No time downtime and you look like a hero for expanding the drive. #WINWIN

Unable to resize a Netapp volume?

There maybe times that you will need or want to re-size a Netapp volume and normally this is process is very easy to do. You can re-size a Netapp volume using  the ONcommand tool, Filerview, or even SSH into the filer directly. Either of these ways is perfectly fine, no wrong way to do it except for when it fails.

A common error I have seen for failed volume re-sizing is due to the “fs_size_fixed”  error.

vol3

The “fs_size_fixed” is a parameter that has been enabled on the volume either during setup or during a snapmirror relationship break. The parameter is there to prevent any type of accidental re-sizing on the volume.  The only way to re-size the volume is to remove the “fs_size_fixed” parameter by connecting directly to filer through an SSH tool and running the following commands. Once the parameter is removed you will be able to re-size the volume.

1. Connect to the filer ( you can use Putty if you have it)
2. First verify that “fs_size_fixed” is enabled on the vol, type : vol status [name of vol]

you will see in the status that “fs_size_fixed” is set to ON

vol1

3.  At the prompt type  : vol options [name of vol] fs_size_fixed off

4. You can confirm that the parameter has been disabled by typing : vol status [name of vol]

vol2

Apple releases iOS 6.1.4 update

Happy Friday everyone!

It looks like Apple has release another iOS update for iPhone 5 on this fine May Friday. The latest update appears to be for audio profile for the speakerphone. Not sure what it really fixes since I didn’t notice any difference after apply the update. Must be something important….

More information on the latest update can be found at http://support.apple.com/kb/DL1652

If you’re unsure on how to apply Apple updates visit http://support.apple.com/kb/HT4623

Duplicate CMIDs and how they affect KMS hosts

The CMID ( Client Machine ID) is a unique ID that is used by a KMS host to activate the license on the machine. Typically each system has it’s own ID and there are no issues but with the use of tools such as cloning the CMID can be duplicated. When the KMS host treats each CMID as 1 client, so if you have 200 systems all containing the same CMID the KMS host has only activated 1 client machine. This results inaccurate licensing activation by your KMS host.

So what causes these duplicates you ask? Normally this is caused by some sort of cloning or imaging of a system that did not sysprep with the sysprep /generalize option, see Microsoft KB929829. I have also seen this happen when you deploy a vm from a vCenter template and you do not use the customization wizard to customize your vm.

vmcustomwizard

Once the CMID is set unfortunately Microsoft does not support changing the CMID, however it is possible to do so. Microsoft does not support changing the CMID and their recommended workaround is too re-image the system using the sysprep /generalize option because changing the CMID may cause the OS to become unstable. With a user’s system that is easier to re-image but let’s say you have several production servers that have duplicate ID’s?

Good luck with telling the application owners that you need to re-deploy their server to fix a duplicate CMID. I’m sure that will go over well. If you work in a company like mine,where that would not fly well, you have 2 options either you live with the duplicate CMIDs ( prevent future duplicates) or change it by resetting the CMID.

If you’re daring like me , I would look for the reset option and test it, to see what happens. Changing or resetting the CMID on a system is technically re-arming the licensing on the system. To re-arm the licenese you will need to logon to the system with the duplicate ID and run the following command:

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

rearm

So there you go, you can change the CMID just keep in mind it’s not support by Microsoft if you do. The best thing to do is just avoid having duplicates by running the sysprep /generalize option when cloning systems. If you’re deploying vm’s just remember to run the customization wizard or have a precanned setting wizard all ready to go.

Unable to Resize iSCSI LUN Using SnapDrive on Windows Server 2003 R2

I recently had another one of my weird Snapdrive issues while trying to resize an iSCSI Lun on a 2003 server. The server is a VM that is using the Microsoft iSCSI initiator and Snapdrive to manage the Netapp provisioned Lun. Re-sizing a lun using Snapdrive is normally very simple but of course on this particular day it was not behaving for me.

Snapdrive appeared to be running ok and didn’t seem to have any issues at all that day. The problem came when I attempted to re size the lun, Snapdrive re-sizing process would fail halfway through. The failure to complete the re-sizing left me puzzled since all connections to the filer appeared to be fine. There was plenty of space left on the volume so it wasn’t a space issue.

Since we were dealing with Windows here we rebooted the server just in case it was pending a reboot or it just needed to “clear it’s  head”. After the reboot I attempted to re-size the lun again and again it failed . The actual failure message was that it was unable to connect to the disk. Odd…It’s connected in Snapdrive , it just won’t resize.

The next thing I thought of was to force a disconnect on the iscsi lun, this way it would forces a disconnect on all connections. The downside to the disconnect was that the Lun would be lost and the SQL databases would need to be stopped. After getting approval to take the server down again, I then proceeded to force a disconnect of this lun. Once all connections were stopped and confirmed they were gone, I then reconnected the iSCSI Lun using Snapdrive.

After the re-connection was completed, I continued with trying to re-size the Lun. BAM! It worked. All it took was a force disconnect , reconnect, then I could re-size. To be honest ,  I wasn’t in the mood to go further digging into a root cause for the failure, especially since I got it working now. I suspect it had something to do with Snapdrive and the iscsi connection it was using since a brand new connection seemed to clear any issues that it had previously. So, if you run into something like this, it might be worth a force disconnect to solve your re-sizing problem.