We have seen some instances of new Windows 8 computers not being able to connect to the internet via Wi-Fi despite all the settings and infrastructure being OK.  The fix is fairly easy: Check the option “Enable Federal Information Processing Standards (FIPS) compliance for this network.” This option can be found on the Security tab of the Connection Properties box (i.e., right-click on the connection, then click Properties.)

Here is where we post tricks we find to be useful, especially those that resolve seemingly intractable problems. Our hours of head scratching and research may save you a lot of time!

All of a client’s workstations were showing un-updated OAB in their Outlooks. When updating was initiated manually, it would fail with error 0x8004010F – object not found. This is with Exchange 2003.

Usually this is caused by the wrong address book being specified within ESM.  However, in this case, that setting was fine.  To be sure, we created another OAB and specified thi new one as default within ESM, but the error continued.

What resolved it in this case was a rather arcane item.  Within the C:\Sindoes\system32 folder is the file MAPISVC.INF and within that file is this line:

6603001f=<server name>    where <server name> is the netbios name of the server

Removing that line and saving the file cleared the problem.

A Windows 7 Professional workstation on a SBS2003 network started getting this error message when logging in.  The instant solution to get them up and running as soon as possible is to temporarily disconnect the workstation from the network, which permits the workstation to log in using cached credentials.  After that, it can be reconnected to the network and it “works.”  However, the network connection is treated as unauthenticated, RDP doesn’t work, and no remote control of the workstation can be done.

Apparently, this can happen if, for some reason, the password associated with the machine account in AD gets out of sync.  One method to fix this is to remove and then rejoin the workstation to the domain.  This is problematic, though, because a new profile will be created on the workstation and you have additional work to clean that up.

This method worked for us very quickly and without having to do any additional work.  This assumes that the login user on the affected workstation has administrator rights on the workstation, which is the proper way to configure them.  All of this is done on the affected workstation.

1. Log in to the affected workstation using the “disconnect from network” trick described above.

2. Follow the steps corresponding to the affected workstation’s operating system (not the server’s):

   Windows 7

• Download the Remote Server Administration Tools (RSAT) package from Microsoft here: https://web.archive.org/web/20150114140323/http://www.microsoft.com/en-us/download/details.aspx?id=7887  (select the proper 32-bit or 64-bit version according to the workstation’s operating system, not the server’s.)
• Install the downloaded package. We had trouble with this until we used clean boot mode, so you may have to restart the workstation after configuring for clean boot, which can be undone after this process.
• Installing RSAT doesn’t automatically make it available to use. Go to Control Panel -> Programs -> Add/Remove Windows Features and look for Remote Server Administrator Tools.  Expand this and drill down to AD/AS / Command line and enable that.

   Windows 10

• Starting with Windows 10 October 2018 Update, RSAT is included as a set of “Features on Demand” right from Windows 10. Do not download an RSAT package from Microsoft. Instead, just go to “Manage optional features” in Settings and click “Add a feature” to see the list of available RSAT tools. Select and install the specific RSAT tool “Active Directory Domain Services (AD DS) tools and Active Directory Lightweight Directory Services (AD LDS) tools.

3. Open a command window as Administrator and enter this command:

NETDOM.EXE resetpwd /s:<server> /ud:<username> /pd:*

Where <server> is the Netbios name of the domain server and <username> is the login account of the affected workstation in the format DOMAIN\Username

That’s it.  After doing this, everything returned to normal on the workstation.