Netsh int ip reset says access denied
netsh int ip reset c:\resetlog.txt

The command must be run in an elevated command prompt windows (WIN+X) and it can be destructive in terms of IPv4 info set on an adapter, so…like don’t run it remotely on a server with a static IP.

I digress. The issue I’m really getting to is related to Homegroup membership and the Windows 10 upgrade. I found that if you’re upgrading from Windows 7 to Windows 10 and the original system you’re upgrading was joined to a homegroup, then the upgraded system might have issues with the TCP/IP stack (I.e. obtaining an IP address via DHCP).

I spent hours troubleshooting this on several freshly upgraded systems running Windows 10 that couldn’t connect to the network because they couldn’t obtain an IP from the DHCP server. All machines exhibited the same issue and all machines were previously joined to a homegroup (not a domain). Here are the symptoms:

  1. The system is upgraded from Windows 7 to Windows 10 build 1511 and works as expected but cannot obtain an IP address via Ethernet or Wi-Fi.
  2. The system works normally if a static IP is assigned.
  3. Resetting the TCP/IP stack results in the following information:
    netsh int ipv4 reset
    Resetting interface, OK!
    Resetting Unicast Address, OK!
    Resetting Neighbor, OK!
    Resetting Path, OK!
    Resetting , failed.
    Access is denied.Resetting , OK!
    Restart the computer to complete this action

In essence having had the systems joined to a homegroup somehow messed up the TCP/IP stack in windows 10 after the upgrade to the point that the system cannot obtain an IP address from DHCP. Here’s how to fix the issue:

  1. Open Regedit.
  2. Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nsi and expand that folder.
  3. Expand the subfolder named {eb004a00-9b1a-11d4-9123-0050047759bc} and right-click the subfolder named 26. Select Permissions… and ensure that for Everyone the Full Control box is checked.
  4. change_network_key_permission_registry_editor
  5. Press WIN+X to open a command prompt with elevated permissions. Type netsh int ip reset and hit enter. Now you should see the following results:
    Resetting , OK!Restart the computer to complete this action
  6. Reboot the system.

WSUS Clean up Query,_removing_unnecessary/?TopicId=59062&Posts=1

DECLARE @var1 INT, @curitem INT, @totaltodelete INT
DECLARE @msg nvarchar(200)
CREATE TABLE #results (Col1 INT) INSERT INTO #results(Col1)
EXEC spGetObsoleteUpdatesToCleanup
SET @totaltodelete = (SELECT COUNT(*) FROM #results)
SELECT @curitem=1
BEGIN SET @msg = cast(@curitem as varchar(5)) + ‘/’ + cast(@totaltodelete as varchar(5)) + ‘: Deleting ‘ + CONVERT(varchar(10), @var1) + ‘ ‘ + cast(getdate() as varchar(30))
EXEC spDeleteUpdate @localUpdateID=@var1
SET @curitem = @curitem +1
DROP TABLE #results

Getting Outlook to Autodiscover Office 365
get-clientaccessserver | set-clientaccessserver –autodiscoverserviceinternaluri ""
Getting Outlook to Autodiscover Office 365

While editing the Service Connection Point in Active Directory Sites and Services does work, it’s probably not the “approved” way to do things.

The support manager recommended that I instead use the Exchange Management Shell to entirely remove the Autodiscover Virtual Directory using Remove-AutodiscoverVirtualDirectory. Here’s how I did that:

1. Open an elevated command prompt and back up the IIS configuration (explained here):

%windir%\system32\inetsrv\appcmd.exe add backup "Before Removing Autodiscover"

2. Open an elevated Exchange Management Shell and retrieve the current autodiscover virtual directory:

Get-AutodiscoverVirtualDirectory | fl Name, Server, InternalUrl, ExternalUrl, Identity

Save the results to a text file in case you need them to re-set the virtual directory later (see Schyler Jones’ comment below on December 2, 2015). Copy the Identity value to the clipboard.

3. In the Exchange Management Shell, remove the autodiscover virtual directory:

Remove-AutodiscoverVirtualDirectory –Identity "<identity value retrieved above>"

You will have to confirm by typing a “Y”.

4. Check that the autodiscover virtual directory is gone:

Get-AutodiscoverVirtualDirectory | fl Name, Server, InternalUrl, Identity

This should now return nothing.

5. Now, with Outlook running on a desktop, hold the Ctrl button, right-click on the Outlook icon in the system tray, and select Test E-mail AutoConfiguration. Enter your email address and password and click the Test button. The results should come from the Office 365 server.

Back to Top