Quickly fix Windows is not Genuine from different Windows versions.

I had an issue today with an old KMS server that some machines had been talking to getting shut down and then the machines months later complaining that they couldn’t find the KMS server.  I  then removed the KMS server’s DNS entries and prevented it from publishing them to dns which had been missed before.  That isn’t the purpose of this post though so if you need more info the below two links help out a lot.

How to remove a KMS Server from your Infrastructure

Additional info for Server 2008 only.

Back to the purpose of my post was when I get tickets for activations (as I have over the past few days) I wanted an easy script to run slmgr, remove the product key, input, and activate the new key.  We use MAK keys in our environment so just for the few machines that were set up for KMS a simple script sounded like an easy way to take care of them. Problem is I run Windows 10 and the machines I was trying to fix were Windows 7. SLMGR.vbs is version specific so although I probably could have copied one off a windows 7 machine I came up with the below solution to work on any version of Windows.  To accomplish this I used our old friend psexec which creates a session runs each slmgr command locally on their machine and outputs the result after prompting for a machine name.  A really simple script but maybe someone will find this useful.  Don’t forget to put psexec in the same directory you run the script from.  Happy Friday 🙂

set /p machinename=Input the PC Name:%=%
PsExec.exe \\%machinename% cscript %SystemRoot%\System32\slmgr.vbs /upk
PsExec.exe \\%machinename% cscript %SystemRoot%\System32\slmgr.vbs /ipk xxxxx-xxxxx-xxxxx-xxxxx-xxxxx
PsExec.exe \\%machinename% cscript %SystemRoot%\System32\slmgr.vbs /ato



Outlook additional mailboxes and from functionality

This is an old issue that I haven’t encountered lately but I was reminded of the other day when adding a shared mailbox for a user and felt a post might help someone else out. Previously I got a request that when sending from a mailbox that had been added as additional mailboxes the from is always sent from the default mailbox not from the additional mailbox unless you go up to options and click the from button to enable the from field and change the from address as shown below.snip_20160602101231

As it is easy to forget to change the from field and kind of a pain to change every time I went on the hunt for an answer to my dilemma.  I can’t seem to find this functionality in Microsoft’s documentation anywhere, but if you add the mailbox as a new email account instead of an additional mailbox the from address will change based on what mailbox you are in when you click new email.  As in the screenshot below you can accomplish this by  going to the file tab and account settings.


To add the mailbox click new on the email tab, then click next.  Then type in the mailbox name and the email address.  The password can be left blank since aslong as you have full access and sendas permissions delegated to the user in Exchange.  Then just click next through the rest of the prompts and finally click finish.


The only caveat to this is that automapping in Exchange adds as an additional mailbox so you might end up with duplicate entries of the same mailbox.  To fix this you will need to add the mailbox permissions through EMC (Exchange Management Console).  Microsoft has instructions on how to add the permissions without automapping in this Technet Article but the command for the EMC is also below.

Add-MailboxPermission -Identity JeroenC -User 'Mark Steele' -AccessRight FullAccess -InheritanceType All -Automapping $false

If you want to fix existing auto-mapping behavior for all the permissions on a particular mailbox the below commands will do the trick.

$FixAutoMapping = Get-MailboxPermission sharedmailbox |where {$_.AccessRights -eq "FullAccess" -and $_.IsInherited -eq $false}
$FixAutoMapping | Remove-MailboxPermission
$FixAutoMapping | ForEach {Add-MailboxPermission -Identity $_.Identity -User $_.User -AccessRights:FullAccess -AutoMapping $false}

So there you have it, a simple fix for someone using a shared mailbox that needs to be able to send from the shared mailbox.
The articles I posted are from Exchange 2010 and Outlook 2010 but I have confirmed the functionality is the same in Outlook 2013 and Exchange 2013.

MDT 2013 Update 2 UDI Wizard – domain join credentials issue

I recently upgraded to MDT Update 2 integrated with SCCM 1602.  Previously I used to install Windows 7 using MDT UDI (2013 I think?) and configured the OSDJoinDomain and OSDJoinPassword variables as collection variables on the collections I had the task sequence.  But after the 2013 update 2 install, on my new task sequence for Windows 10 they would show up like the below and it wouldn’t join the domain.


So thanks to some help on this TechNet forum we were able to come up with a workaround.

  1. Create two custom variables and place them just before the UDI Wizard step in your task sequence.  One will be the account used to join the domain and the other the accounts password.Capture4.PNGCapture5
  2. Then open up the UDI Wizard Designer and on the new computer details page under “domain join credentials” put in the custom variables you setup into the default value boxes (remember to use %% around your task sequence variables).Capture6
  3. Then simply save your changes and update your MDT Toolkit package in SCCM.  Then you should be all set.