Saturday, September 23, 2017

Domain re-join shortcut trick

We've all had it. A system with domain authentication issues. Usually its the Secure Channel.


or way back



 but sometimes its worse like the machine object being "accidentally" deleted.

For me to resolve these, I just login with cached credentials and run some PowerShell like

 Test-ComputerSecureChannel -repair  

or in worse case when the object is not present

 add-computer -Domainname domain.mycompany.com –cred “MYCOMPANY\kevin.fason”  

No matter how many times I lead these tech horses to water they just wont drink up PS1 cmd-lets.  I notice my techs will just rejoin it to the domain via the GUI. They MUST use the mouse for whatever reason. The accepted way is to remove it from the domain and make it a member of a workgroup, then join back to the domain with reboots in between and enabling a local admin account etc.

Instead of going through all that, did you know you can just enter the NetBIOS name of the domain? The system perceives this as you moving the system from one domain to another, even though its technically the same one, your just using the legacy NetBIOS name vs the FQDN of the domain.

Here is an example normally showing the FQDN of the domain:


Just change it to the NetBIOS and select OK. One reboot. all done. After the reboot it will revert to the FQDN domain name.


If you do not know what it is you can open a command/powershell prompt and type 'set USER' and it will tell both names via the USERDNSDOMAIN (FQDN)and USERDOMAIN (NetBIOS) variables. 

Or if you must use that mouse, you can open ADUC, right click the domain and select properties. Right on the general tab you will see it listed under 'Domain name (pre-Windows 2000).

Who knows how long this will work as forest/domain functional levels are uplifted.



Thursday, July 27, 2017

ConfigMgr Upgrade Readiness Connector Setup



NOTE 07.27.2017 - I thought I posted this a while back so hopefully the steps and screenshots are still valid. I'll go validate when I have some time.

---

We are using Windows Upgrade Readiness to accelerate our transition from our legacy versions of Windows to 10 v1607. As we recently updated ConfigMgr to 1610 I wanted to make use of the connector available in SCCM for it.

To give a brief overview, we have the Readiness Scripts Deployment folder (with our info) in an SCCM package with the deployment set to run the BAT file. The deployment has a recurring assignment schedule to run once a month, the week before our monthly patch cycle. Its ran on all workstation OS' including Windows 10) as it is expected to be used well past our 7/8.1 migration to 10 but also from one build version to another in Windows 10 itself as Readiness lets you pick the destination version to work against. Quite handy. Definitely keep up on the teams blog if you use it and the team itself is great with communication and interaction with the world. I've had great conversations with them over this offering.

Here is a sample of the end result that you can see in the ConfigMgr console.I'll cover this more later.



So for the setup of the connector, the documentation was a bit more generic then I would have liked, especially around the OMS and Azure bits, so I did struggle a little on it so here is how I set it up. There are three basic steps to it:

  1. Create an Application in Azure for SCCM to use, think of it as the username/password
  2. Enable permissions to the OMS instance Upgrade Readiness is in
  3. Setup the ConfigMgr to Windows Upgrade Readiness connector

This assumes you have Readiness already setup in OMS. I prefer the older manage web console to the newer portal one so thats where I perform the first step.


Step 1


Log in to the Manage portal and navigate to Active Directory on the left pane. Then click on your AD instance under name.


After that you select APPLICATIONS at the top



Then select Add at the bottom



Choose Add an Application my organization is developing


Give it a useful name such as ConfigMgrUpgradeReadiness and click on the right arrow.


Now you have to create two URLs, neither of which are used so enter whatever you want



Now you can create the Client ID and key that ConfigMgr uses to pull data. You can think of this as the username and password that ConfigMgr uses.

Select your newly created Application and click Configure at the top. This takes you to its customization.



Two parts here. First is  to copy the CLIENT ID somewhere as you will need it. Second is to select the duration of the key as 1 or 2 years. Once saved it will show you the key. you will want to copy the key as well. I would suggest you retain the client ID and key somewhere such as a password manager as you may need it long term. If not then you have to come back here and generate a new one.



Note that you only get ONE opportunity to copy the key. Once you leave this page the key will not be shown (as above) and you will have to generate a new one. You are now done with overall step 1.


Step 2


For step two you need to give this app the correct permissions. This was removed from the manage portal a while ago so over to the new portal. Select Resource Groups on the left pane.

As shown below you will select the Resource Group the Upgrade Readiness is located in (mms-eus in this example) then Access Control (IAM) on page 2 and finally +Add on page 3.


You will then select or search for the name of the Azure AD app you created earlier and grant it Contributor rights. This was my struggle. I originally thought you had to give rights to the domain SCCM service account thinking it was what ConfigMgr accessed OMS with. This is shown above highlighted in yellow.

Step 2 is complete and its onto Step 3, setting up the connector in ConfigMgr.

Step 3


For this you goto the SCCM Console and navigate to \Administration\Overview\Cloud Services\Upgrade Analytics Connector. Note it has not been updated to 'Readiness' yet.




Simply right click Upgrade Analytics Connector and choose Create Connection to Upgrade Analytics.

Enter the relevant information you saved from step 1 above which is the Client ID and secret key along with your Azure Tenant name, generally mycompany.onmicrosoft.com. Once done select Verify then Next.




Note this screenshot is AFTER I already entered it and you'll see the Client secret key: field is blank. If you ever go into here you will have to re-enter the key. You remembered to save it right?

If you setup the permissions correct you will be shown with the required information. This screenshot is post setup also.


Thats it., SCCM will now pull from Windows Upgrade Readiness. You can view information about it in the DMPDownloader.log located in your SCCMInstallFolder\Logs. While I suggest you save the key and Client ID somewhere, it is located in this log file but the logs may have rotated by the time you need either of them.

This is a sample of a normal run. The last line I do not like and wish it could be changed. Upgrade Readiness updates daily, however SCCM will download from it only once a week (10080 minutes) so your data is that old.


Final Thoughts


Once it has imported into SCCM you can act on it. Just goto \Monitoring\Overview\Upgrade Analytics. Per my initial screenshot, it shows readiness information for the All Workstations collection I've created. Just select any collections in your environment that are device based to work against.


At the bottom you can select the pull down and create collections based on the "buckets" that are in Upgrade Readiness. I have created several that in turn have the in-place TS advertised to them as available. It does create these with 'All Systems' as the limiting collection so I have changed that to use more appropriate ones to coordinate with any implementation schedules.

My firm has a small team that spends time every few days in the Upgrade Readiness OMS website so as systems are marked as ready in the Readiness tool then flows via the connector into ConfigMgr Collections to get Windows 10 in-place advertised to that endpoint as being available. Awesome right?

-Kevin

Monday, July 24, 2017

ESXi Windows Server Backup Tool Bare Metal Restore

I have a small single host ESXi on a Dell PowerEdge R710 (popular for homelab) that I support for family. It has all the normal stuff on it:

  • Windows Domain Controller with DHCP
  • Windows Domain Controller
  • General Purpose server for WSUS, MDT and what not. 
  • Multiple MDT Build and Capture 
  • Multiple Windows 10 Insider Preview
  • ???

All normal homelab stuff. Recently there was a power loss event, that while it lasted only a few minutes; and should not have been noticed, hadcaused the battery in the UPS that protects this host to blow up, literally, so all the VMs and the host went down hard.

There is an physical Ubuntu Linux server and network equipment that is on a different (matching) UPS and it controls both UPS' so if a power loss happens it will SSH into the ESXi host and pause the VMs and shut it down gracefully if needed. Sooooooo did not plan for batteries exploding.

While we recently bought VMWare vSphere Essentials, which gives us the backup API, its not in use just yet. When both the host and the VMs were setup it used the free license so everything else used free options. Therefore to protect the "critical" Windows Server VMs, we used the built in Windows Server backup tool and did a daily Full Server backup. These are sent to a UNC path on the above Linux server as it has lots of space and is external. Due to limitations in the built in backup software only a single full backup is done so no incremental.

So upon bypassing the UPS and bringing the host and VMs back up, one of the Domain Controllers was not happy and kept blue screening and in a restart loop.


Solutions on this error were to go through Directory Services Repair Mode. Thankfully this was the DC that is only a DC, no FSMO roles or duties so was pretty disposable. Since the backup is ran daily it was less then 24 hours old I decided to do a bare metal restore instead since its been a while since I did a restore exorcise.

First step was to shut it down and take a snapshop so I can revert and go the Repair Mode route if I chose to. Then boot the VM from the 2012R2 Install ISO.

Select Next on the initial dialog


Then Repair your computer at the bottom



then Troubleshoot



and then finally System Image Recovery



Since my backup is not local and on a Linux server it will error out so we need to get connected to Samba on the Linux box.


Choose Cancel to close this dialog then select Next to proceed




Then you click on Advanced... so you can enter a UNC path.


Here you would locate a backup on the network, however the second option reminded me that I used VMXNET3 for the NIC on this VM and the driver is not in the 2012 R2 install media since its installed by the VMWare Tools. 



If you try to attach to the UNC path you will just get an error since there is no NIC present in this PE instance. You can verify further by going to a Command Prompt in Advanced Options and using ipconfig etc.


previously wrote on where to source the drivers but that meant getting a source (floppy or CD) mounted on this broken VM. There is a simpler solution for ESXi. I edited the VM and added a second NIC that is supported by the media, which in this case is an E1000e.


After giving a few seconds for DHCP to kick in I selected Back until I could select Advanced... again then select Search for a system image on the network which then asks if you want to bring the network up.



Select yes and enter the UNC to your backups


and of course credentials to get at the backups


Now we have all our Server Backups so we can select the one we want and then Next 



It then asks us which volumes to restore. Since its a DC and only has the one so we select it and Next again.


Since it is bare-metal and going to the same "hardware" you just need to select Next here as we have nothing to change.


And now we are at the confirmation dialog. Finally! Just have to select Finish and let it restore.


Nope, still one more dialog to be sure we are REALLY ready to restore. Select Yes.



Away it goes.



This is weird. Got an error on the restore. I would get this error again each time I tried but in different spots so the backup seemed good to me still.


This is such a generic error I thought it may be NIC related so I went back to ESXi and created a small drive on the multipurpose Server VM



and then copied the backup to it. Note you need to create a folder in the root called WindowsImageBackup then place the systems backup folder in it. Once completed, I unmounted it from that VM and mounted to this broken VM



and ran through the wizard again. All live, the PE instance was seeing all the hardware changes I was making. This time the wizard found it at the beginning since it was local to the VM so I did not have to go through Advanced like before.


After selecting Next you are taken to the Choose additional restore options dialog and its the same from there on out like above, just no errors this time!


Once complete it restarted and the restored server booted back up in its earlier state.


I did however interrupt the restart and unmounted the restore volume and deleted the e1000e NIC I attached. I looked at the event logs to make sure AD replication was happy and then after a couple days I removed the snapshot I took in the beginning. 

Without the ESXi parts at play, Windows Server backup can be a free yet powerful tool to backup servers and restore them. On physical hardware you could copy the backup to a USB if you had the same NIC issues.

Now to work a process around exploding UPS batteries. As a preventative measure, I did copy out the same day backups of the other two servers in case they had this happen but am happy to say they have been running great since this incident happened several weeks ago. Until I have time to research free ESXi backup options that work with my VMWare Essentials license I have added these backups to my rsnapshot.conf on the Linux box to get quasi incremental backups.

-Kevin