How to Check if Processor Supports SLAT (Second Level Address Translation)

If you want to run Hyper-V on newer Windows operating systems (Like Windows 8 or Windows Server 2016), your processor must support SLAT or Second level address translation.

What is SLAT?

SLAT is a technology which was introduced in both Intel and AMD processors. Intel calls this technology EPT (Extended Page Tables) while AMD refers it as RVI (Rapid Virtualization Indexing). Hyper-V uses this technology to reduce CPU time and save memory for each VM.

How to Check if Processor Support SLAT?

You can check your processor SLAT support by following these steps.

Step 1. Download Coreinfo.exe form this link, https://technet.microsoft.com/en-us/sysinternals/cc835722

Step 2. Extract it to your C:\ drive

Step 3. Open command prompt with elevated privileges

Step 4. Navigate to C:\ drive

Step 5. Run the following command

coreinfo.exe -v

If your processor support SLAT, there should be an * in EPT row.

Software Center Failed Updates

  1. Rebuild the software distribution folder

    net stop wuauserv
    net stop bits
    rename <c:\windows\SoftwareDistribution SoftwareDistribution.bak>
    net start wuauserv
    net start bits

  1. Clear the Catroot 2 folder contents
    Open an elevated Command Prompt, type the following command one after the other and hit Enter:

    net stop cryptsvc
    md %systemroot%\system32\catroot2.old
    xcopy %systemroot%\system32\catroot2 %systemroot%\system32\catroot2.old /s

    2a) delete all the contents of the catroot2 folder
    2b) net start cryptsvc

  2. Try the install again after 15-20 min

How to Automatically Rotate HyperV Snapshots

The following instructions can be used to set up a rotating snapshot schedule for all the Virtual Machines that are running in Hyper-V on the server. The default rotation for this script is 7 days which can be modified depending on your preference.
 
Warning
In order for this script to run successfully, you will need to make sure you have additional space on your hard drive to hold the snapshot history.
Each snapshot consists of RAM snapshots as well as changes made to the virtual hard drive since the last snapshot.  This means that if you have a VM with 4GB of RAM and you want 7 days of snapshots, you will need a minimum of 7days*4GB of RAM = 28GB of additional disk space in order to accommodate a VM that has completely static data.  In actuality, it is not unreasonable to plan for up to 4 times this amount of disk space to accommodate hard drive data changes.
 
Create the Snapshot Script
  1. Log into your server through Remote Desktop. For instructions on how to login to your server,
  2. Run PowerShell from the Start menu or your desktop.
  3. Run the following script.
    1. setexecutionpolicy RemoteSigned
  4. When the Execution Policy Change warning is displayed enter Y.
  5. Open Notepad and paste the following contents into it. (Note line 1 where you can change the number of days for your rotation):
    1. $Days = 7 #change this value to determine the number of days to rotate.
    2. $VMs = GetVM
    3. foreach($VM in $VMs){
    4.     $Snapshots = GetVMSnapshot $VM
    5.     foreach($Snapshot in $Snapshots){
    6.         if ($snapshot.CreationTime.AddDays($Days) lt (getdate)){
    7.             RemoveVMSnapshot $Snapshot
    8.         } 
    9.     }
    10.     CheckpointVM $VM
    11. }
  6.  Save the file as C:\SnapshotVMs.ps1
  7. Open Task Scheduler (press your Windows key and start typing Task Scheduler).
  8. In the Actions section click Create Basic Task and follow the wizard to set up the following parameters:
    • Name:  CUSTOM – SNAPSHOTVMS > Next
    • Trigger:  Daily > Next
    • Daily: select 11:00:00 PM Recur every: 1 days > Next.
    • Action:  Start a program > Next.
    • Program/Script:  type PowerShell
    • Add Arguments:  type C:\SnapshotVMs.ps1

  9. Check the box for “Open the Properties dialog for this task when I click Finish” and click Finish.
  10. In the General tab, in the Security Options section, select the option to Run whether user is logged on or notClick OK
  11. Enter the Administrator credentials that you use to log into your server. Click OK.
  12. In Task Scheduler click on Task Scheduler Library.
  13. Locate and right click on the CUSTOM – SNAPSHOTVMS task you created.
  14. Run the scheduled task to verify that it executes correctly. If successful, you will see a PowerShell console open and a snapshot created for all servers in Hyper-V Manager.
  15. Log in the following day to verify that all VMs on the server have a snapshot on them in Hyper-V Manager.

TempDB Shrink

use tempdb
GO

DBCC FREEPROCCACHE — clean cache
DBCC DROPCLEANBUFFERS — clean buffers
DBCC FREESYSTEMCACHE (‘ALL’) — clean system cache
DBCC FREESESSIONCACHE — clean session cache
DBCC SHRINKDATABASE(tempdb, 10); — shrink tempdb
dbcc shrinkfile (‘tempdev’) — shrink db file
dbcc shrinkfile (‘templog’) — shrink log file
GO

— report the new file sizes
SELECT name, size
FROM sys.master_files
WHERE database_id = DB_ID(N’tempdb’);
GO

IIS website is only listening on 127.0.0.1 and not IP address

I recently had this problem, and even after ensuring that the bindings for the website were linked to all unassigned addresses, I could still only connect via the loopback address, 127.0.0.1. The first troubleshooting step was to look at all listeners using:

netstat -an

I noticed I had an entry for port 80 for 127.0.0.1, but not for my actual IP address—nor for 0.0.0.0:80, which would be all IP addresses:

TCP 127.0.0.1:80 0.0.0.0:0 LISTENING

The next step was to look at the actual HTTP IP listeners. Because I only had an IP present for 127.0.0.1, I added a listener for my real IP address and performed an IIS reset. I then had a listener on 127.0.0.1 and my physical IP address, and I could connect to the server via the IP address.

C:\>netsh
netsh>http
netsh http>show iplisten

IP addresses present in the IP listen list:
-------------------------------------------

127.0.0.1

netsh http>add iplisten ipaddress=100.76.72.126

IP address successfully added

netsh http>show iplisten

IP addresses present in the IP listen list:
-------------------------------------------

127.0.0.1
100.76.72.126

netsh http>exit


C:\>iisreset

Attempting stop...
Internet services successfully stopped
Attempting start...
Internet services successfully restarted

C:\>netstat -an
 TCP 100.76.72.126:80 0.0.0.0:0 LISTENING
 TCP 127.0.0.1:80 0.0.0.0:0 LISTENING

Another approach would have been to remove the 127.0.0.1 listener so there were no explicit IP addresses configured for the HTTP, which would have meant it would have listened on all IP addresses (this would actually be my preferred approach):

C:\>netsh
netsh>http
netsh http>show iplisten

IP addresses present in the IP listen list:
-------------------------------------------

127.0.0.1
100.76.72.126

netsh http>remove iplisten ipaddress=127.0.0.1
The following command was not found: remove iplisten ipaddress=127.0.0.1.
netsh http>del iplisten ipaddress=127.0.0.1

IP address successfully deleted

netsh http>del iplisten ipaddress=100.76.72.126

IP address successfully deleted

netsh http>exit


C:\>iisreset

Critcal error: TF30046: The instance information does not match. Team Foundation expected xxx which was not found. Please contact your Team Foundation Server administrator.

This scenario is for After Restoring TFS Database 2013

  1. Open Database instance in Sql Server Management Studio and open database TFS_Configuration
  2. Go to tbl_ServiceHost table and look for entry where Name  = “TEAM FOUNDATION”. Copy the HostId
  3. Go to TFS INSTALL FOLDER \Application Tier\Web Services folder
  4. Open the web.config and update the value for applicationId  key with the value copied in step 2
  5. IISReset
  6. net stop tfsjobagent
  7. net start tfsjobagent

Test Network Connectivity with the PowerShell Test-Connection Cmdlet

Since the first time computers were networked together, people have had to test their connections. Just like a dial tone that tells you the phone is ready to use, many IT pros want to make sure they have a remote connection before beginning their ‘call’. For IT pros, this has traditionally meant using the PING utility that has existed since forever. It still works, and you can even use it in PowerShell. But when used in PowerShell, you get text output that’s hardly useful for scripting. So let me give you some additional options. Some of these cmdlets have changed through different PowerShell versions. I am testing from a Windows 8.1 desktop running PowerShell 4.0. If something doesn’t work for you, be sure to read cmdlet help and examples.

The PowerShell Test-Connection Cmdlet

The PING utility works by sending a special type of packet, an Internet Control Message Protocol echo request (ICMP), to a remote computer. Similar to the way a sonar pings another submarine, PING sends out a probe and waits for a response. The PowerShell equivalent is the Test-Connection cmdlet. This cmdlet is actually a wrapper for the Win32_PingStatus WMI class, but it’s easier to use because it’s a cmdlet. All you need to do is specify a remote computer name or IP address. The assumption is that you are testing a connection to another computer in your domain.

Using the Test-Connection cmdlet in Windows PowerShell. (Image Credit: Jeff Hicks)

Using the Test-Connection cmdlet in Windows PowerShell. (Image Credit: Jeff Hicks)

By default, the cmdlet sends four pings, but you can send out more or less.

The output has been formatted for your viewing pleasure. If you pipe a connection result to Get-Member, then you’ll discover the actual property names.

Discovering property names for our test connection. (Image Credit: Jeff Hicks)

Discovering property names for our test connection. (Image Credit: Jeff Hicks)

The cmdlet allows you to specify multiple computer names:

Specifying multiple computer names with the Test-Connection cmdlet in Windows PowerShell. (Image Credit: Jeff Hicks)

Specifying multiple computer names with the Test-Connection cmdlet in Windows PowerShell. (Image Credit: Jeff Hicks)

If you merely want to test a connection, then you should use the –Quiet parameter. Instead of response data, you get a simple true or false that indicates whether the computer responded to a ping request.

Using the Test-Connection cmdlet to test a connection with the -quiet parameter. (Image Credit: Jeff Hicks)

Using the Test-Connection cmdlet to test a connection with the -quiet parameter. (Image Credit: Jeff Hicks)

Here’s an example of where you might use this in a script:

This command is getting all computer accounts in the default computers container and pinging each name once. If the computer responds, PowerShell passes the ADComputer object down the pipeline, where I’m simply writing an object with a single property of Computername.

I could continue adding to the pipelined expression any cmdlet that accepts pipeline input by property name for Computername.

Or you might try something like this:

Using the Group-Object cmdlet to organize results in Windows PowerShell. (Image Credit: Jeff Hicks)

Using the Group-Object cmdlet to organize results in Windows PowerShell. (Image Credit: Jeff Hicks)

Using the Group-Object cmdlet, I’ve organized my results based on whether they responded or not.

Using PowerShell’s Test-NetConnection cmdlet

The Test-Connection cmdlet is included out of the box in PowerShell. If you are running Windows 8 or later, then you probably have the NetTCPIP module, which includes another command called Test-NetConnection. This command will provide additional connection information.

 The Test-NetConnection cmdlet in Windows PowerShell. (Image Credit: Jeff Hicks)

The Test-NetConnection cmdlet in Windows PowerShell. (Image Credit: Jeff Hicks)

Even better, it works with external hosts. Assuming that the host is configured to respond to pings, of course.

The Test-NetConnection cmdlet in PowerShell has failed because the host isn't configured to respond to pings. (Image Credit: Jeff Hicks)

The Test-NetConnection cmdlet in PowerShell has failed because the host isn’t configured to respond to pings. (Image Credit: Jeff Hicks)

However, you can use this to test for connectivity to common ports.

Using the Test-NetConnection cmdlet in PowerShell to test for connectivity to common ports. (Image Credit: Jeff Hicks)

Using the Test-NetConnection cmdlet in PowerShell to test for connectivity to common ports. (Image Credit: Jeff Hicks)

You can test for SMB, HTTP,RDP, or a PING.

Using the Test-NetConnection cmdlet in PowerShell to test connectivity for RDP. (Image Credit: Jeff Hicks)

Using the Test-NetConnection cmdlet in PowerShell to test connectivity for RDP. (Image Credit: Jeff Hicks)

I also appreciate that I can do a trace route with this command,

Performing a trace route with the Test-NetConnection cmdlet in Windows PowerShell. (Image Credit: Jeff Hicks)

Performing a trace route with the Test-NetConnection cmdlet in Windows PowerShell. (Image Credit: Jeff Hicks)

This leaves me with this result:

The trace route was not successful. (Image Credit: Jeff Hicks)

The trace route was not successful. (Image Credit: Jeff Hicks)

Granted, this may not be the result I want, but clearly there are some devices along the way to Petri.com that won’t respond to ping requests.

Finally, this command also can be used for simple Boolean testing.

I tested to see if my NAS server is available. Here’s another example: I want to see which servers do not have Remote Desktop enabled.

Using the Test-NetConnection cmdlet in PowerShell to determine which servers that don't have Remote Desktop enabled. (Image Credit: Jeff Hicks)

Using the Test-NetConnection cmdlet in PowerShell to determine which servers that don’t have Remote Desktop enabled. (Image Credit: Jeff Hicks)

Using the Test-WSMan cmdlet in PowerShell

Most of the testing I’ve shown thus far involves ICMP pings, where the computer or firewall must be configured to allow. It is also possible that the network adapter will apply to a ping even though the operating system is hung. If you want to verify that the remote computer is ready for you, you can try using the Test-WSMan cmdlet. By this point I am assuming you have deployed PowerShell to your servers and enabled remoting. If not, you are making your life much more difficult. This cmdlet will verify that you can connect with the WSMan protocol, which means you can take advantage of the CIM cmdlets and remoting cmdlets like Invoke-Command.

Using the Test-WSMan cmdlet in PowerShell. (Image Credit: Jeff Hicks)

Using the Test-WSMan cmdlet in PowerShell. (Image Credit: Jeff Hicks)

Here’s why this might be useful. The remote computer CHI-Win81 is up and running and replies to pings.

The command has failed. (Image Credit: Jeff Hicks)

The command has failed. (Image Credit: Jeff Hicks)

But when I try to do something with it, the command fails because the WinRM service is not running on the client. It would have been better to try testing first.

Testing with the Test-WSMan cmdlet. (Image Credit: Jeff Hicks)

Testing with the Test-WSMan cmdlet. (Image Credit: Jeff Hicks)

Unfortunately, Test-WSMan doesn’t have any parameters to provide a simple Boolean response.

As a result, I wrote a simple wrapper function.

This command will give you a simple true or false result. If you use alternate credentials and get a false re-try with –Verbose so you can see the error message.

You now have a variety of testing tools that I encourage you to use if you are scripting a process that involves a large number of computers. As always be sure to read full help and examples for everything I’ve shown you.

Source and Credits:

Test Network Connectivity with the PowerShell Test-Connection Cmdlet

Case of the Logon Attempt Failed RDP Connection

This issue will occur if the dependency services are disabled. Please make sure the following services are enabled and running.

–      DNS Client

–      Function Discovery Resource Publication

–      SSDP Discovery

–      UPnP Device Host

We can see from the security logon that successful connections are using Package Name (NTLM only):    NTLM V2

On the Server 2008 R2 box, in secpol.msc we can see LM & NTLM is refused (As it should be…)

image

However the client had a group policy, that had been enabled to allow a legacy application to connect to ancient Windows servers, this forced Send LM & NTLM responses

image

Now the bad way to fix this, is to change the server to a less secure setting (i.e. Send LM & NTLM responses)

While it is best to eliminate servers that still require LM or NTLM, and use the “refuse LM & NTLM” setting, you can compromise by changing the client policy to allow LM & NTLM, but use NLTM v2 if available, this will at least prevent you from downgrading security on your servers running more recent Windows operating systems.

clip_image002

CBS log and CBS persist in %Windir%\logs\CBS

Batchfile

:: This batch file stops CAB and CPS files filling up temporary storage caused by Trusted Installed and Windows Update services.
@ECHO OFF

:: Title for Batch Script
title The Fumigator

:: Display Text
Echo Executing The Fumigator, hold your breath.

:: Stop Windows Update Service
net stop wuauserv

:: Delete all files/folders WITHIN Temp directory
del /f/s/q C:\Windows\Temp > nul
rmdir /s/q C:\Windows\Temp

:: Rename Folder
Rename  C:\Windows\SoftwareDistribution C:\Windows\SoftwareDistribution.old

:: Start Windows Update Service
net start wuauserv

:: Wait 30 seconds (User can't skip)
timeout /t 30 /nobreak

:: Delete Folder
RD /S /Q "C:\Windows\SoftwareDistribution.old"

:: Wait 10 seconds (User can't skip)
timeout /t 10 /nobreak

:: Stop Windows Module Installer
net stop TrustedInstaller

:: Delete all files/folders WITHIN CBS directory
del /f/s/q C:\Windows\Logs\CBS > nul
rmdir /s/q C:\Windows\Logs\CBS

:: Wait 60 seconds (User can't skip)
timeout /t 60 /nobreak

:: Start Windows Module Installer
net start TrustedInstaller

:: Query the WSUS server for its needed patches
wuauclt.exe /detectnow

:: Display Text
echo.
echo.
echo.
echo Your CAB files are no longer an issue.
echo.
echo.
echo This script was written by ***** on behalf of *****.

:: Leaves window open
PAUSE

Thank you PHSA for sponsoring me in the Administering a SQL Database Infrastructure (M20764) for my 70-462 Exams

COURSE OVERVIEW

In this course, professionals who administer and maintain SQL Server databases and who develop applications that deliver content from SQL Server databases will gain the knowledge and skills to administer a SQL server database infrastructure.

This course incorporates material from the Official Microsoft Learning Product 20764: Administering a SQL Database Infrastructure and can assist you in preparing for the 70-764: Administering a SQL Database Infrastructure exam. 

GK Digital Learning is also available with digital Microsoft Official Courseware (dMOC).

  • Authenticate and authorize users.
  • Assign server and database roles.
  • Authorize users to access resources.
  • Protect data with encryption and auditing.
  • Recovery models and backup strategies.
  • Back up SQL Server databases.
  • Restore SQL Server databases.
  • Automate database management.
  • Configure security for the SQL Server agent.
  • Manage alerts and notifications.
  • Manage SQL Server using PowerShell.
  • Trace access to SQL Server.
  • Monitor a SQL Server infrastructure.
  • Troubleshoot a SQL Server infrastructure.
  • Import and export data.