Windows PXE Boot Issues – KB4493467 (April 9, 2019)

Microsoft has acknowledged an issue with PXE boot affecting Windows 8.1 and Windows Server 2012 R2 systems caused by a Security-Only update (KB4493467) released on April 9, 2019.

The Issue:

After installing this update, there may be issues using the Preboot Execution Environment (PXE) to start a device from a Windows Deployment Services (WDS) server configured to use Variable Window Extension. This may cause the connection to the WDS server to terminate prematurely while downloading the image. This issue does not affect clients or devices that are not using Variable Window Extension.

The Workaround:

To mitigate the issue, disable the Variable Window Extension on WDS server using one of the following options:

Option 1:
Open an Administrator Command prompt and type the following:

Wdsutil /Set-TransportServer /EnableTftpVariableWindowExtension:No

Option 2:
Use the Windows Deployment Services UI.

  1. Open Windows Deployment Services from Windows Administrative Tools.
  2. Expand Servers and right-click a WDS server.
  3. Open its properties and clear the Enable Variable Window Extension box on the TFTP tab.

Option 3:
Set the following registry value to 0:

HKLM\System\CurrentControlSet\Services\WDSServer\Providers\WDSTFTP\EnableVariableWindowExtension”.

Restart the WDSServer service after disabling the Variable Window Extension.

Microsoft is working on a resolution and will provide an update in an upcoming release.

Please like & share:

Fix WordPress “Destination Folder Already Exists”Issue

I encountered an issue with my WordPress hosted site when I was attempting to install a plugin, in this case the WP Statistics plugin. I know I had previously installed this plugin but it did not show up in my installed plugin list in the WordPress Admin dashboard. The installation fails with an error: “Installation failed: Destination folder already exists.”

When you install a WordPress theme or plugin, WordPress will extract and copy the folder from a zip file into the wp-content/themes or wp-content/plugins directory. If the folder already exist, then WordPress is unable to copy the files and therefore generates the error. This can happen if the theme or plugin files that are already installed are missing or corrupted.

Here’s the fix for this issue:

  • Use a FTP client such as FileZilla, and connect to your WordPress site.
  • Drill down into the wp-content/plugins directory and delete the plugins folder which you are having issues with. In my case the WP Statistics plugin folder.
  • Once the folder is deleted, go back to your WordPress admin site and reinstall the plugin. You should see a successful installation and at which point, you can activate the plugin and configure the settings if necessary.
Please like & share:

ConfigMgr Guidance For SQL CE Levels

What is Cardinality Estimation or SQL CE Level?
The Cardinality Estimator is a SQL Server Query Processor component that is responsible for predicting the number of rows that the query will return. Microsoft provides some great documentation about SQL CE which you can read more on Microsoft Docs.

As for how SQL CE works and it’s importance with ConfigMgr, Umair Khan of Microsoft has shared a great blog post explaining the details, which you can read more here:
https://blogs.technet.microsoft.com/umairkhan/2019/01/28/configmgr-current-branch-1810-guidance-for-the-sql-ce-levels-with-various-sql-versions

Please like & share:

Finding and Removing Unused VMware Horizon View Replica Virtual Machines

vmware-vr-1

Purpose

This article provides steps to find one or more unused replicas in the datastore and to safely remove them.

Resolution

If the parent virtual machine or snapshot is changed in the pool settings, a new replica virtual machine is created. The previous replica becomes unused and is deleted after the recompose completes. The View composer automatically deletes the replica from vCenter Server and the Composer database. Under certain conditions, the replica virtual machine information may exist in the Composer database and the vCenter Server Inventory after any linked clone associated with the replica is deleted. This results in an unused replica.

Finding and removing unused replicas

To find and remove unused replicas:
  1. In vCenter Server or the server where the composer is installed, stop the VMware View Composer service.Note: When this service is down, no recompose, refresh, or provisioning operations occur. Use a convenient maintenance window.
  2. Click Start, type Services, and Press Enter.
  3. Click VMware View Composer Service.
  4. Click Stop.
  5. Click Start > Run, type cmd, and click OK. The command prompt opens.
Note: In the Windows Server 2008 machines, the command prompt must be run as an Administrator.
To run the command prompt as an Administrator:
  1. Click Start > Run, type cmd, and click OK. The command prompt opens.
  2. Hold Ctrl + Shift, and press Enter.
  3. Navigate to the View Composer install directory.
    • On a Windows 32-bit server, navigate to C:\Program Files\VMware\VMware View Composer.
    • On a Windows 64-bit server, navigate to C:\Program Files (x86)\VMware\VMware View Composer.
  4. Run the sviconfig.exe command with the FindUnusedReplica operation:

    SviConfig.exe -operation=FindUnusedReplica -DsnName=DSN_Name -Username=User_Name -Password=Password

    Where:

    • DSN_Name is the name of the compose database DSN
    • User_name is the user name of composer database owner
    • Password is the password of composer database ownerFor example:SviConfig.exe -operation=FindUnusedReplica -DsnName=ComposerDB -Username=sa -Password=secretNotes:
    • If the DsnName contains spaces, use quotes around the value.
    • If there are two composer databases on the server due to an older database, and the command is run against the incorrect database, the currently used replicas is moved to the unused folder as the old database does not recognize them.

    To determine the Composer DB DSN, user and password:

    1. In the vCenter Server hosting the Composer service, Click Start > Programs > Administrative Tools > Data Sources (ODBC).
    2. Click the System DSN tab.
    3. Click the Composer database entry. This is the value you enter for DsnName in the sviconfig command.
    4. Click Edit.
    5. The username is visible and should match the entry in the Composer configuration in the View Manager.
  5. If the command finds any unused replicas, they are listed in a new file created in the current directory ( unused-replica-*.txt).
  6. Unused replicas can be unprotected and moved to a unique folder with the parameter:-move=trueFor example:SviConfig.exe -operation=FindUnusedReplica -DsnName=ComposerDB -Username=sa -Password=secret -Move=trueNotes:
    • When using the move=true option, you receive warning pop-ups. These are safe to ignore.
    • Note the UnusedViewComposerReplicaFolder is created automatically if it does not exist, and unused replicas are moved to this folder.
  7. Open a vSphere Client and connect to vCenter Server.
  8. Click Inventory > VMs and Templates.
  9. Remove the replicas located at the UnusedViewComposerReplicaFolder.
  10. Start the VMware View Composer service.
Note: To view the help file for findUnusedReplicas:
  1. Click Start > Run, type cmd, and click OK. The command prompt opens and navigate to the View Composer install directory.
  2. Run this command:SviConfig.exe -operation=findUnusedReplica

Additional Information

See Also

Please like & share:

PCoIP connections to VMware Horizon View 5.1.x / 6.1 Desktops With Multiple Network Adapters Fail

PCoIP connections to VMware Horizon View 5.1.x / 6.1 desktops with multiple network adapters fail (2062604)

Symptoms

  • Attempting to connect to Horizon View desktops with multiple network adapters fail.
  • You see errors similar to:
    • Unable to launch from Pool <pool> for user <domain/user>: There were no machines available that reported protocol [PCoIP] as ready
    • The Display Protocol For this Desktop is currently not available
    • The connection to the remote computer ended
Note: The issue can also be observed when connecting to View desktops having single network adapter.

Resolution

To resolve this issue, configure the subnet that the View Agent uses by setting the value for the subnet mask registry in Parent Virtual Machine.
Warning: This procedure modifies the Windows registry. Before making any registry modifications, ensure that you have a current and valid backup of the registry and the virtual machine. For more information, see Microsoft KB article 136393.
Note: The preceding link was correct as of June 17, 2015. If you find a link is broken, provide a feedback and a VMware employee will update the link.
To open the Windows Registry:
  1. Click Start > Run, type regedit, and click OK.
  2. Go to the registry key – HKEY_LOCAL_MACHINE\software\vmware inc\vmware vdm\node manager\subnet.

    For View 6.1 – Go to the registry key HKEY_LOCAL_MACHINE\software\vmware inc\vmware vdm \IpPrefix
  3. Set the value to n.n.n.n/m (REG_SZ). Note: where n.n.n.n is the TCP/IP subnet and m represents the number of bits in the subnet mask.
For more information:

Source: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2062604

Please like & share:

Windows 7 Network Controller Issues – KB4338818 (July 2018)

The July 2018 Windows Updates for Windows 7 SP1 and Windows Server 2008 R2 SP1 introduces a bug that could cause the network interface controller to stop working. The update referenced is KB4338818.

In case your systems run into this issue, the workaround from Microsoft is to do the following:

Please use your best judgement and evaluate the risks of applying this update to your Windows 7 SP1 and Windows Server 2008 R2 systems.

** Update **
According to an IT Pro who opened a support case with Microsoft, this is the information provided at this time:

“Regarding the known issue in the July monthly rollup about the network interface controller that will stop working. We are still looking at the data gathered from multiple customers and we do not have a list third party software that is causing the issue. What we do know until now, is that the issue is reproducing mainly on VM over VMware.”

Please like & share:

Fix For Error: Failed To Process Configuration Manager Update 0x87d20b15

With the release of version 1710 for System Center Configuration Manager Current Branch on November 20, 2017, I pursued to update my ConfigMgr 1706 site to take advantage of some of the exciting new features, which you can read more here! Use this PowerShell script to enable the early update ring for ConfigMgr 1710.

I tested the update in my test lab and the upgrade to v1710 worked just fine. As usual with my production environment, I always run the prerequisite checker to make sure nothing is flagged as an issue, which in my case all was fine with green checkmarks. However, the actual installation of the update failed on the Installation step for “Upgrade ConfigMgr database” as seen in the screen capture above. The description for the error indicates: [Failed]: Upgrading ConfigMgr database. Check cmupdate.log for details.

The following is an error was seen in the cmupdate.log: Failed to apply update changes 0x87d20b15

I located a blog post by my friend Anoop dated from October 2016 referencing a similar error code where he points to providing the NT Authority/System account in SQL with the sysadmin security role, however that was not the cause of my upgrade failure and the security roles were already defined correctly. The following TechNet thread was a dead end as well.


My post on Twitter as seen above caught the attention of another friend of mine, David James, Director of Engineering for ConfigMgr at Microsoft, who with his team were able to pinpoint the problem in no time at all and quickly provided a solution which resolved my ConfigMgr 1710 upgrade installation hang up. Thanks David and to the ConfigMgr team! The gist of the problem is that my environment had an old compatibility level 100 set for the SQL Server database for the CM_XXX database, and you can find this referenced in the cmupdate.log file. Changing it to 110 fixed the compatibility level needed for ConfigMgr 1710.

Run the following query in SQL Management Studio (please change XXX to your ConfigMgr Site Code) and retry the installation via the Update and Servicing node in the ConfigMgr Admin Console. This also addresses the issue where TRY_CONVERT is not recognized as a built-in SQL function:

ALTER DATABASE CM_XXX SET COMPATIBILITY_LEVEL = 110

SUCCESS!!

** Additional Mention **

Check out this blog post, “In Telemetry We Trust?” written by a friend and fellow ConfigMgr admin, Peter Egerton, who shares a similar experience and the positive nature of telemetry data especially in the ConfigMgr space.

Please like & share:

How To Fix: Bitlocker Recovery Key Prompts On Every Reboot

windows-10-bitlocker-featured

There are few reports of users having Bitlocker issues following the October 2016 patches.

The issue: On every reboot, the Bitlocker recovery key is required which is quite disruptive and cumbersome. As a workaround in order to solve this issue, the following steps can be taken:

On the next reboot and once in Windows, reset Bitlocker by disabling and re-enabling it.
In administraive command prompt, do the following:
manage-bde -protectors c:-disable
then do this:
manage-bde -protectors c:-enable

At this time, I’m not certain on which patch is causing the issue but I wanted to share this info to help. You can also discuss in this TechNet post.

Follow (@Hoorge) on Twitter and join Tech Konnect on Facebook and Twitter (@TechKonnect) to stay current on technology related matters.

Please like & share:

System Center Operations Manager (SCOM) Console Crash

scom-gsx-solutions

** UPDATE**
(October 19, 2016)
A fix for the SCOM console crash issue as previously blogged below has been released. See the following KB320006 article to obtain the hotfix.

***************************************************************************************************

**Posted on October 18, 2016**

There is a widespread report of System Center Operations Manager (SCOM) 2012 R2 / 2016 console crashes due to some bugs in October 2016 Cummulative Updates, in particular with the following patches: KB3194798 / KB3192392 / KB3185330 / KB3185331.

The product team has acknowledged the issue on their blog post and is said to be working on releasing a fix soon. The current recommendation is to uninstall the problematic patches as a temporary workaround. According to the blog post, an announcement will be made on the SCOM Team blog when a fix has been made available. So, keep a close eye on it.

Links related to this post:

SCOM Product Team Console Issue Ackowledgement
TechNet Discussion
SCOM Product Team Blog
Microsoft Tech Community Discussion

Follow (@Hoorge) on Twitter and join Tech Konnect on Facebook and Twitter (@TechKonnect) to stay current on technology related matters.

Please like & share: