Possible Fix for Object Browser Issue

[cgrace70]

Product, version and build: 5.2.120
32 or 64 bit version of product: 64-bit
Operating system: Windows 10 Pro (Home PC) and Windows 7 Pro (Work PC)
32 or 64 bit OS: 64-bit
PowerShell Version: 5

Like a few other posters I was having a problem with the PSS 5.2.120 upgrade and not all the cmdlets showing under their respective modules in the Object Browser. I could look at "V5 - 64-Bit" and have different results when switching to "V2 - 64bit" or both 32-Bit environments. I had the exact same problem with both my home PC (Windows 10 Pro 64-Bit) and my work laptop (Windows 7 Pro 64-Bit).

The problem affected both custom modules as well as some offical ones, like the "ActiveDirectory" PowerShell module. The AD module would only show the Get-ADUser cmdlet. After a (frustrating) week of tyring to find some combination of uninstalling PSS 5.2.120, reinstalling it, cleaning the cache, rebuild the cache, deleting the cache folder, fixing the registry (in a number of different orders) and activating/deactivating the license. I finally found the fix for both systems.

On both systems I had upgraded from PSS 5.2.117 to PSS 5.2.118 to PSS 5.2.119 and finally to PSS 5.2.120, as the different versions were released. I decided to try and uninstall PSS 5.2.120 one more time. However, this time I downloaded the archive of PSS 5.2.117 and installed it first. I launched the application and it updated the Object Browser properly. Next, I went straight to the PSS 5.2.120 upgrade and voila, everything appeared in the Object Browser as I would have expected.

Q: Could the PSS 5.2.118 and/or PSS 5.2.119 updates have broken something that could only be fixed by going back to PSS 5.2.117 and then applying PSS 5.2.120? It seems to have worked for me. Hopefully, it will work for others.

[davidc]

We recently found an issue with the module cache that causes some module cmdlets to be orphaned. Thankfully we fixed the issue on our end and it will be included in the next service release.

David

[davidc]

Please try the latest service build: v5.2.121.

David

[cgrace70]

Unfortunately, that did not work. I installed 5.2.122 this morning and it still does not look right.

What I did:

I closed PSS.
Deleted the contents of "C:\ProgramData\SAPIEN\PresetCache 2016"
Ran CleanCache.exe (just because)
Restarted PSS and waited for it to build the cache information.

Afterward, (in the Object Browser) the Microsoft "ActiveDirectory" module only shows the cmdlets "Get-ADObject" and "Get-ADUser". Some other third-party modules "AudioDeviceCmdlets" and "PSExcel" don't show anything under v2/v5 32-bit/64-bit.

The modules are available if I "Get-Module -ListAvailable". I can import them without issue and run all the cmdlets from the PS console. No issues with build 5.2.117 and before.

[davidc]

We don't recommend deleting the Pre-Cache folders. You will need to repair the installation in order to restore the files.

As for the incomplete cmdlets, we will investigate the ActiveDirectory module. Note: Third party modules may have host restrictions that might prevent them from being cache.

In the meantime, we are going to email you instructions and a link to download a script that will allow you to generate the necessary pre-cache files. Please zip and attach the generated files to this topic.

David

[cgrace70]

Thanks. I only deleted the Pre-cache folders after uninstalling PSS. I thought they were automatically removed during the uninstall, but this time the folder was still there.

I received the instructions and ran the script on both my home system and at work. I got mixed results. The Activedirectory module seemed to be fine, but the other two third party modules still had no cmdlets listed or they were only partially listed.

I decided to take things a step further and it appears I was able to resolve the issue on my work system, as I will attempt to explain. I haven't tried it at home yet.

- Uninstalled PowerShell Studio 2016 completely.
- Removed any lingering folders.
- Removed the third-party modules PSExcel and AudioDeviceCmdlets. I did not touch the Activedirectory module.
- Cleaned up the registry with CCleaner.
- Rebooted the system.
- Manually installed PSExcel and AudioDeviceCmdlets, as per the instructions found on their respective websites (GitHub repositories), using:

New-Item "$($profile | split-path)\Modules\{module name}" -Type directory -Force

NOTE: Previously, I had used "Install-Module -Name {module name}", as per the developers instructions. This puts the modules in:

"C:\Program Files\WindowsPowerShell\Modules\{module name}"

NOTE 2: I seem to recall this being a problem with PSS and another module a while back, when it was put in this folder.


- Installed a fresh copy of PSS 5.2.122.
- Opened PSS and refreshed the cache.


It appears everything is fine with most of the modules now. The exception is AudioDeviceCmdlets. It is a .dll (not a .psm1) and though it appears in the Object Browser under the v2 environment, it does not contain any cmdlet references. I'm not sure if the module is actually supported in v2, as I cannot find a reference at this stage. I only work with it in the v5 environment.


UPDATE:

AudioDeviceCmdlets is supported in v2. I didn't think to use the console in the PSS v2 environment. DUH!
So, that would be an outstanding issue. The cmdlets appear in v5, just not v2. The script you provided will not Export from a .dll module.