Blog: Networking

Certain applications are hardcoded to write certain files\folders to shared portions of the operating system (%ProgramFiles% or %ProgramData%). This can present issues, for example when running RDS or Citrix if the files pertain settings\data that need to be unique to each user.

Since Windows 2000, Microsoft supports so called junction points. NTFS junction point is NTFS functionality that allows you to seamlessly redirect one folder into another.

Since Windows Vista\2008, full symlinks were introduced. While junction points can only link to directories on a local volume, symlinks are much more powerful and actually supports all 4 R(emote) and L(ocal) scenarios – L2L, L2R, R2R and R2L. Another great benefit of symlinks is that you can use it to redirect files (and not only folders). So if you need to only direct a single file, you don’t have to redirect the whole folder.

Here is a link to the technet article explaining the available options available with the MKLINK command: http://technet.microsoft.com/en-us/library/cc753194.aspx

We received Event ID:333 "An I/O operation initiated by the Registry failed unrecoverably. The Registry could not read in, or write out, or flush, one of the files that contain the system's image of the Registry." On Windows 2003 R2 terminal server running SEP 12.1.

We could reproduced the issue by simply running a SEP scan. We notice all user registry hives from everyone that has logged in are loaded into the registry's HKEY User directory for scanning. Depending on how many users have logged into the server, this can quickly add up. When this happens, it causes the registry memory to become so low that it fails to write any new data to the registry until the server is restarted. [more]

The first event logged would generally state that the system's available memory for the registry was low. After that, Event ID: 333 would be logged about every 30 seconds.

We found this article that helped resolve this issue http://www.symantec.com/connect/forums/event-id-333. In the article are some memory pool settings in the registry with a link to: http://support.microsoft.com/default.aspx?scid=kb;EN-US;312362.

In the article, it states for PagedPoolMax, "Setting the value at 60 informs the Memory Manager to start the trimming process at 60 percent of PagedPoolMax rather than the default setting of 80 percent. If a threshold of 60 percent is not enough to handle spikes in activity, reduce this setting to 50 percent or 40 percent."

During our testing, the value of 60 still exhibited the low resource issue. Setting the PagedPoolMax value to 40 (decimal) along with the other TCP chimney settings stopped the registry errors from Symantec scans.

Recently an external DVD drive was not accessible using Windows 8.1.  The device didn't show up in explorer and device manager indicated "Windows cannot start this hardware device because its configuration information (in the registry) is incomplete or damaged" and it indicated "Code 19" as additional information.[more]

I tried uninstalling and then scanning for hardware changes but the same error occurred.

Finally, I found a technet article that showed promise (http://technet.microsoft.com/en-us/library/cc772156%28v=ws.10%29.aspx) which linked to http://support.microsoft.com/kb/929461?fwLinkID=192798 if the offending device is a CD or DVD drive.

Even though the subsequent article indicates it is for Vista, the solution worked for Windows 8.1. Of course, I saved a copy of the applicable registry subkey before making any changes - just in case I needed to undo my changes. However, the change fixed the problem.

Exchange users could connect to their mailboxes (OWA and Outlook), but any attempt to send email resulted in the message being stuck in the Drafts folder (when using OWA) and the Outbox (when using Outlook). The Exchange submission service would never see the email and attempt to send it. All users could receive email without any issues. The most common reasons for this type of problems are DNS, IPv6, and firewall. However, all of these were investigated extensively and no issues were found. The issue was resolved by unmounting the Exchange database, restarting the Microsoft Information Store service, and remounting the Exchange database. Afterwards, all email in user mailboxes that was “stuck” was queued for delivery.

To copy a VM from ESX to Workstation, or vice versa, you can use the VMware Standalone converter, but a faster way may be to just copy the vmdk files from one technology to the other.  Details about how this can be found here: http://sostechblog.com/2011/03/30/moving-vms-from-esx-to-workstation/

If the Active Directory security groups that are created during the initial install of Exchange 2013 get removed unintentionally, they can be recreated by running the setup /prepareAD command. This is pretty well documented, but be sure to use the setup files from the most recent version of Exchange installed in the environment. If the Exchange environment is made up of mixed builds, always use the most up-to-date build for running the setup /prepareAD command. Cumulative update builds count as well, not just service packs.

While verifying Windows patches were up to date on a few Windows 7 clients, WSUS showed one PC needed some updates with approval: "install" but status: "not installed." Running Windows Update check on the PC was not showing any updates available from the WSUS. The WindowsUpdate.log file was showing differently that there were updates detected matching the number that WSUS showed with approval: "install", but Windows Update would never install them.[more]

Recreating the Software Distribution folder on the client seemed to have resolved this synchronization problem.

1. Stop Windows Update service
2. Rename C:\windows\softwaredistribution folder  
3. Start Windows Update service and check again for updates.  It will recreate the softwaredistribution folder automatically.

Windows Update now showed the missing updates to install from WSUS server.

 

 

After migrating an Orion server to its own standalone server and a separate SQL server (the server was installed with a SQL Express instance running on the same VM). During the re-setup process, we needed to enter the SA account credentials to log into the migrated database. We found the username as “SolarWindsDatabaseUser”, but had no idea what the password was. The original setup never prompted to enter the password and seemed to generate it itself. After some research, we found it is stored in SWNetPerfMon.db in the Orion subfolder of the install – C:\Program Files (x86)\SolarWinds\Orion\SWNetPerfMon.db. This is just a plaintext file that you can open in notepad/wordpad.

PROBLEM: Regular (non-admin) user selects to ‘Repair Adobe Reader Installation’ from the Help menu within Adobe Reader application. After repair is completed, the user is prompted to restart the machine. If Adobe Reader is running on a multi-user server (RDS or Citrix XenApp), selecting yes to reboot the machine would forcibly disconnect all other users sessions which could interrupt their work.[more]

CAUSE: The user was able to do this because the Reader update\repair was performed by the Windows Installer running in the System context.

SOLUTION: Disable Adobe Reader repair option by adding the following registry key (specific to Adobe Reader XI):

• 64bit OS - HKLM\Software\Wow6432Node\Adobe\Acrobat Reader\11.0\Installer\
• 32bit OS - HKLM\Software\Adobe\Acrobat Reader\11.0\Installer\
  • “DisableMaintenance”=DWORD:00000001