Life was simpler when we had DVD Drives and a wallet full of CD/DVDs! I was building an HP DL360 This morning and needed to install Windows. I created a bootable USB with Unetbootin and selected a Windows Server ISO, it wouldn’t boot. So I thought ‘Fine I’ll play the game” I pressed F10 for Intelligent Provisioning.
After selecting USB media – the system could not see my USB Drive?
After a couple of seconds head scrathing the penny dropped, it wants the iso not a bootable drive, (doofus!) So I used a FAT formatted USB and that didn’t work either?
Option 1: Use iLO
Before you all start emailing me, you can install an operating system from virtual media WITHOUT and advanced iLO licence! Annoyingly I was building the server on the bench, so I had to connect my laptop into the iLO with a crossover cable but, here’s me proving it works.
Option 2: Use ExFAT
Format your USB drive using ExFAT, luckily I use macOS and Disk Utility will format a drive using ExFAT for me.
Note: Windows will also format as ExFAT 🙂
Then simply put your install .iSO file(s) on the media.
Now you can see your install media.
Option 3: Use the HP Media Creator
I didn’t try this option, but feel free to download it and give it a try, comment below to let me know how you get on.
In vSphere 5 and earlier versions this was not a ‘fun’ job at all, many times I sat down to do it, and lost the will to live. Now there’s a nice new tool built into vCenter that does ‘most’ of the hard work for you. Here I’m using the vCenter appliance but the tool is also available on the Windows version.
For my certificates I’m using Microsoft Certificate Services. I’m going to issue a ‘Subordinate CA’ certificate to my vCenter Appliance, then it can issue signed certificates to each of its services.
Solution
Make sure you have published a ‘Subordinate Certification Authority’ certificate template.
Connect the the vCenter appliance using SSH and enable ‘shell’
[box]
shell.set --enabled True
shell
[/box]
Create a directory to store our certificates and requests in, then launch the certification-manager tool.
The app will launch, and present you with a bunch of options.
Select option 2 > No we don’t want to use the configuration file > enter your logon information, (administrator@vsphere.local and password) > Enter all the items required for the certificate request.
Choose option 1 (Generate Certificate signing request) > Specify the folder you created above, (/root/SSLCerts) > Two files will be generated > Enter ‘2’ to exit.
The files;
vCenter 6.5
vmca_issued_key.key (the private key)
vmca_issued_csr.csr (the request)
vCenter 6.0.0
root_signing_cert.key (the private key)
root_signing_cert.csr (the request)
Now we need to get the CSR (signing request).
[box]
cat /root/SSLCerts/vmca_issued_csr.csr
OR
cat /root/SSLCerts/root_signing_cert.csr
[/box]
Copy the certificate PEM file.
Open the web enrolment portal of your certificate services server, (https://server.domain.com/certsrv) > Request a certificate > Advanced Certificate Request > Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file, or submit a renewal request by using a base-64-encoded PKCS #7 file > Paste in the PEM text > Remember to use the Subordinate Certificate Authority template > Submit.
Base 64 Encoded > Download Certificate > Save it somewhere you can find it, and give it a sensible name!
Now download the Base 64 version of your CA certificate from the main page of your certificate services website, (press ‘back’ a few times).
Now back in your SSH session, change to your SSLCerts directory, and create an ’empty’ file to paste our certificate information into.
[box]
cd /root/SSLCerts/
touch vmca_signing_cert.cer
vi vmca_signing_cert.cer
[/box]
Open the certificate for the vCenter Appliance in a text editor, and PASTE INBELOW it, the text from the Root-CA certificate. Then copy ALL the text to the clipboard, and go back to the SSH session.
Paste the text you have coped into the open ‘vi editor’ page (Press I, then P) > Save and Exit (Press Esc > :wq {enter})
If you ‘ls’ (thats list short, or dir if you are a Windows type), you will see you now have a .CSR, a .KEY and a .CER file. (the names of which vary between version 6 and 6.5).
Version 6.5
Version 6.0
Launch the certificate-manager application again > Option 2 again > No (again) > Login (again) > ‘N’ > Option 2 (Import custom certificate(s)) > Give it the path to the certificate file > Then the path to the key file.
Back in Part One we setup our migration admin account, and installed ADMT. Now, as I’m going to migrate the users passwords I need a ‘Password Export Server‘, but first I need to tackle the subject of user SIDs
Solution
Domain Migrations and SID Filtering
Every user has a SID (Security Identifier) it’s the thing AD uses to refer to and apply security to users, (and other objects). This is why you can rename a user and it’s security does not change, (because the SID always remains the same). Why is this important for domain migrations? Well if you’re a doing a migration that’s taking place over a period of time, users in the NEW domain may still need access to things IN the OLD domain, (like file shares, printers, applications etc).
This is a problem because when you setup a domain trust it Enables SID filtering, back in part one it told you this, here. So if a user in newdomain.com tries to access a folder, (they could access before the migration,) in olddomian.com they wont be able to do so, (because their SID has changed, to a new SID in the new domain. Even if you migrated their old SID if get’s filtered out as the user comes back over the trust).
How do we fix that? We need to do two things,
Migrate the users old SID to newdomain.com (This then become their, sIDHistory attribute)
Disable SID filtering in olddomain.com (To allow the sIDHistory attributes to come back over the trust)
This lets users in the new domain have their NEW SID, and their OLD SID.
Migrating the users SID is simple, (it’s just a box you tick when running a migration, you will see that later). Disabling SID filtering can be a little confusing. Where do you do it, and which way round do you execute the command? Above I’ve solved the first one for you you Disable SID Filtering on the OLD domain. The following diagram will explain why;
Usually users DON’T have a sIDHistory. attribute, (unless they’ve been migrated before!) They only have a SID (objectSID attribute.) To demonstrate let’s jump forward in time, and look at a migrated user (ABarksdale)
Click to enlarge the above image, and inspect the users SID (objectSID) and old SID (sIDhisttory) attributes.
As the name implies, this is a piece of software that runs on the source domain, (on a domain controller,) that ADMT uses to migrate user passwords. Before you can do this, you need to create a ‘key’ in the NEW domain, (where ADMT is running). Then, you use that key to setup the password export server in the OLD domain.
password: can be anything you want, but you will need it to setup the password export server, so don’t forget it.
If it runs OK, find your keyfile, then copy this to the domain controller in the old domain you are going to install the password export server service on.
Theres two versions of the password export server software, (a 32 bit and a 64 bit version.) Download and install the version applicable to your source domain controller.
Note: The install requires a reboot of the server, you might want to do this at the end of the day.
The install is pretty simple, Accept the EULA, browse to the keyfile, and enter the password you used above.
Specify a user account to run the service as, (I just use the ADMTAdmin account we’ve already created).
Finish the install, and let it reboot.
After a reboot, if you look in the services (Start > Run > services.msc). You will see the ‘Password Export Server Service’.
Note: You will also notice the startup type for the service is ‘Manual’. ONLY start this service, when you are actually migrating passwords.
ADMT: Granting Local Rights to ADMT user in the Source Domain.
To migrate machines, the ADMTAdmin user needs “Local” administrative access on all the source machines. The easiest way to do this is via group policy, using ‘Restricted Groups’. This allows you to take a group (or user) and put put them on the local groups (including administrators) of the targeted machines.
In the OLD domain, create a group and put the ADMTAdmin from the target domain in it. (I put the domain admin from the target domain in it as well, to be on the safe side, but that’s up to you).
Note: You may see this a few times while doing migrations, notice above the user icon there’s a small red curved arrow (below), that logo denotes ‘Foreign Security Principle’, it’s not really our user at all, it’s a special object that AD creates in a hidden OU, (turn on advanced mode in AD users and computers you can see them.)
Create a new GPO that will apply to the computers/servers you are going to migrate.
To test it has applied, on a client run ‘gpresult -R’ at an administrative command prompt.
You can of course, simply check the local administrators group to make sure the new group is in there.
ADMT: Additional GPO Note
To perform computer migrations, (and security translations), ADMT needs to deploy an ‘agent’ to the machines in the OLD domain. The local firewall (if enabled) can stop this, I simply disable the local firewall. (If someone wants to send me a list of ports to add, to make it work I’ll publish the). But even the Microsoft Documentation on Technet says disable the firewall.
Create a new GPO linked to where your source computers are, (here I’m just linking to the root of the domain).
In addition I have also seen the agent fail to deploy if the ‘Remote Registry Service’ is not running on the target machines, (it’s disabled by default). So I use this policy to turn that on as well.
In the same GPO navigate to;
[box]Computer Configuration > Polices > Windows Settings > Security Settings > System Services[/box]
Locate the ‘Remote Registry’ service, and set it’s startup to automatic.
Firefox is what I use when Opera does not work, so when I tried to connect to some management servers that did not support Opera this happened;
Secure Connection Failed An error occurred during a connection to {FQDN). SSL received a weak ephemeral Diffie-Hellman key in Server Key Exchange handshake message. (Error code: SSL_ERROR_WEAK_SERVER_EPHEMERAL_DH_KEY)
Solution
Navigate to ‘about:config’ > I’ll be careful, I promise!
In the search bar type ssl3.dhe_rsa_aes_128_sha > change its value to false.
In the search bar type ssl3.dhe_rsa_aes_256_sha > change its value to false.
Related Articles, References, Credits, or External Links
If you are used to setting up DNS records, then the BT Web Portal (btdomainmanager.com) can be a little confusing. I was stuck yesterday, luckily I had another client I could get to check their records for me.
Solution
In the example below I’ve got two IP addresses to which I want mail delivering to, 123.123.123.123 and 123.123.123.125, (yours may be on completely different ranges, that’s OK.)
In addition to the two MX records, I’ve also setup two A (host) records that point the host-names mail and mail2 to those two IP addresses.
Note: Most of you, will only have one IP address, and one host record to create.
Related Articles, References, Credits, or External Links
A client who we recently did a WDS (Windows 7) install for, needed to image a couple of Windows XP machines, (They had some software that either would not run, or was not supported on Windows 7).
They asked me for some documentation on how to do this, it’s been such a long time since I imaged any XP machine, so I took the opportunity to document it properly.
Solution
Before you begin, be aware you need to be building your reference machine with a Volume Licenced copy of Windows XP NOT an OEM or Retail copy (i.e. DONT build the machine with manufacturers rescue disks like Dell or HP). If you don’t do this you will need to activate every Windows machine that you deploy with Microsoft.
Make sure the version of sysprep you are using is at the same service pack level as the reference machine or bad things will happen.
1. Build your reference machine, and configure it as you require.
2. Create a folder on the root of the C: Drive called ‘Sysprep”. Insert the Windows XP CD and locate the Deploy cabinet file. (This is ‘like’ a zip file and it’s in the supporttools folder).
3. Double click the support cab, then copy over the sysprep.exe file, the setupcl.exe file and the setupmgr.exe file to your c:sysprep folder.
4. You can now run sysprep.exe and skip to step 13. BUT if you require an answerfile (a script that will answer all the questions Windows will ask while it’s reinstalling post sysprep) then run the setupmgr.exe program, at the welcome screen click next.
5. Create New > Sysprep Setup > Windows XP Professional.
6. Fully Automate > Enter Name and Organisation > Set the Display Properties.
7. Set Time Zone > Enter the Volume Licence unlock code > If you are joining a domain, I suggest generating a random name then changing it later.
8. Set the Local Administrators password > Typical settings will enable DHCP > Supply any domain and domain credentials you need to join your domain.
9. Telephony (I just skip this) > Regional Settings > Languages.
10. Printers > Run Once commands > Additional Commands.
11. Enter a string that will go into the registry, and can be identified later > Finish > Accept the default save path > OK > At this point it looks like it’s crashed, you can manually close the setupmgr.
12. Now you can run sysprep.exe > OK > I select ‘mini-setup’ (If you don’t, it will run the welcome to windows session and play the annoying music you cant turn down!) > If you have installed applications and are going to image the machine click Reseal > OK.
Note: Factory will literally set the machine back to a ‘day one’ install of Windows XP.
The machine will then shut down and can be imaged.
Final Note: If you power it back on, it will rebuild itself and delete the c:sysprep directory. Which is fine unless you are doing some testing and realise you have to do the whole thing from scratch!
Related Articles, References, Credits, or External Links
If you have a machine setup and working on your wireless network, sometimes it’s easier to set other machines up by simply migrating the settings. Either because you don’t want your child to try and type in a 64 bit WPA key, or you might simply have forgotten the WEP/WPA key,and don’t want to go through all the hassle of setting it up again.
In a small business environment you can give your colleagues their wireless settings in an XML file, or on a USB thumb drive. When using XML files you can even script the deployment of wireless settings to your users.
Solution
Option 1: Export/Import wireless Networks to XML File.
This is quick and easy, and if you are feeling adventurous enough, could be used to script the deployment of wireless networks.
1. On your working wireless machine, open a command window, the following command will list all the wireless profiles that are installed on this machine, )in the example below there is just one).
[box]netsh wlan show profiles[/box]
2. Now we know the name of the profile (Note: Typically it will be the SSID), we can export it to a folder. Be aware if the folder does not exist, the process is liable to fail.
Option 2: Export/Transfer/Import wireless Settings via USB.
1. On the source machine open ‘Control Panel’.
2. Select ‘Network and Sharing Center’.
3. Select ‘Manage wireless networks.
4. Locate the wireless profile you want to migrate, (in the example below there is just one), double click it > select ‘copy this network profile to a USB flash drive’.
5. Assuming you already have a USB drive plugged in, the wizard will detect it > Next.
6. Close.
7. Take the drive to a destination machine, and plug it in, Windows 7 has autorun disabled, with older versions of Windows you can simply choose ‘Connect to wireless network” from the autorun menu. If not open the drive and run the setupSNK.exe file.
8. Yes to confirm.
9. OK to close.
10. Your network is setup and ready to go.
Related Articles, References, Credits, or External Links
If you need to connect to your wireless network with a new machine and have forgotten the key, you can view the WEP or WPA key in cleartext using the following procedure on a machine that has connected before.
2. To show all the wireless profiles stored on this machine, issue the following command;
[box]
netsh wlan show profiles
[/box]
3. From the output above, the wireless profile I want the key for, is called SMOGGYNINJA-N. Note: This is the same as the Wireless networks SSID. To view the wireless key in clear text use the following command;
[box]netsh wlan show profiles name=”SMOGGYNINJA-N” key=clear[/box]
You can also export the profile from one PC to another one, (so you don’t have to enter the key on the new PC), with the following two commands.
Copy the WiFi folder you created in the step above, to the new PC/Laptop. Then execute the following command. Note: Change the section in red to match the path to your XML file.
I jumped on a clients remote desktop services server today and saw;
However when I went to activate;
Windows couldn’t be activated
Error Code: 0xC004F074
Error Description:the Software Licensing Service reported that the product could not be activated. No Key Management Service (KMS) could be contacted. Please see the Application Event Log for additional information.
Solution
Out of the box this version of Windows has installed with a KMS Key, that’s fine if you are going to run KMS, here’s how to set it up. But if you want to activate with MAK key or a retail key then you need to manually change it.
1. Press Windows Key+R > cmd {enter} and execute the following command;
