Blog: .NET Framework

We had a banking customer with a FiServ application consistently crashing under Windows 10. The crash would always display a .Net framework error. All users of this application were having issues with it, but the severity changed from user to user. One user would crash once every couple of hours, while the other would crash once every other day. No user was doing the exact same thing, and no other errors were showing before the crash. It seemed to be a completely random occurrence.
FiServ support could not recreate the issue and advised we update to Windows 10 1803. While updating a PC to test this solution I checked the event logs and noticed a printer kept trying to map every 60 minutes and fail. It just so happened that whenever this printer failed to map, the .Net error would also show up on event logs. Group Policies were refreshing and triggering the printer mapping error. I launched the application and ran a "gpupdate" and sure enough, the application crashed. I looked into the GPO's and found the drive that was mapping the location of the program was set to "replace" instead of "update" or "create". This was causing the file path to be lost every time there was a group policy update. I changed this drive map to "create" and it resolved the issue.


After installing Windows 10 from scratch, I noticed some applications would occasionally need .Net Framework 3.5. If I went to Programs and Features then Windows features to install .Net Framework 3.5, it would ask to download from Windows update which would always fail. I found a KB article at that indicated I would have to use the Windows 10 installation DVD (or ISO) as the source for the updates. This was accomplished by editing Group Policy on the local system:

Going to Computer Configuration -> Administrative Templates -> System

then enabling Specify settings for optional component installation and component repair

then, in the Alternate source file path, point to the DVD or ISO sources\sxs folder


You then need to run the gpupdate /force command then add the .Net Framework 3.5 Windows feature.


A customer’s Outlook Active Sync stopped working for their phones. I connected to their 64-Bit Exchange 2007 server and found that nothing in IIS was working.

Looking at the event logs found where .NET 1.1 had been installed right before IIS stopped working.

IIS 6.0 supports both 32-bit and 64-bit. However IIS 6.0 does not support running both at the same time. ASP.NET 1.1 runs only in 32-bit mode. ASP.NET 2.0 runs in 32-bit mode or in 64-bit mode. Therefore, if you want to run ASP.NET 1.1 and ASP.NET 2.0 at the same time, you must run IIS in 32-bit mode. However Microsoft Exchange Server 2007 only supports Microsoft.NET 2.0, 64-bit version.

The problem was that Microsoft .NET Framework 1.1 was installed on the Exchange server and broke IIS since it is running in 64-bit mode for use with Exchange 2007.

  • I uninstalled .NET 1.1
  • Went to a command prompt
  • Used the following command to disable the 32-bit mode:
    cscript %SYSTEMDRIVE%\inetpub\adminscripts\adsutil.vbs SET W3SVC/AppPools/Enable32bitAppOnWin64 0
  • Then used the following command to install the version of ASP.NET 2.0 and to install the script maps at the IIS root and under:
    %SYSTEMROOT%\Microsoft.NET\Framework64\v2.0.50727\aspnet_regiis.exe -i
  • Restarted IIS, World Wide Web Publishing Service, and HTTP SSL

[more]After completing the steps above everything began functioning as it should.

I found that the reason .NET 1.1 was installed, was because all the management server sessions were being used and access to the VM host was needed. An installation of Virtual Infrastructure  Client 2.0 was started but canceled on the Exchange server. VI Client 2.0 requires .NET 1.1 which was automatically installed before the VI installation was canceled.


I was assisting a vendor with a software update at a client site that required .NET 3.5 SP1. An error keep popping up (“remote user install not available”) when I attempted to install .NET 3.5 SP1.  RGBRast was listed as the problem child. I looked at group policy as many web post suggested.

(Computer Configuration: Administrative Templates: Windows Components:Windows Installer) (Disable Windows Installer) Set to "Disable"

The group policy was not set so I went ahead and disabled the setting to see if it would help, but it did not.

After researching more I found that with .NET 3.0 and up, the RGB Rast msi appears to be configured to do a per-user install, rather than per-machine. The server had the "Prevent per-user installs" Group Policy enabled which would cause the install to fail, preventing .Net 3.5  from installing. [more]

I modified the registry value

Key: HKLM\Software\Policies\Microsoft\Windows\Installer
Value: DisableUserInstalls
Data: 1

And was then able to complete the .NET 3.5 SP1 installation as well as the database / program upgrade.