IManage Filesite 9.3.1 throws 'The system cannot find the file specified error' when checking documents out in Windows 10 - windows-10

I have a newly built windows 10 machine. We have a ActiveX control that hooks into Imanage and opens a requested document. On my old machine this ActiveX control worked as expected but on the new PC I am getting a Imanage error dialog.
One or more documents could not be checked out. The operation could not be performed on these document(s). The document XXX could not be checked out. The system cannot find the file specified.
I am using IE 11 with the same security settings. As I am getting an Imanage error, that implies that the ActiveX control is working thus Imanage is the issue?
I am using Filesite 9.3.1 on both machines. I am not an expert on Imanage and how it works so I could be missing something simple.

There are two reasons that this could be happening:
As already mentioned by Yevgeny, the NRT locations may be invalid, the locations are stored in the registry at:
NRTEcho:
HKEY_CURRENT_USER\Software\Interwoven\WorkSite\8.0\Common\General\Echo
NRPortbl:
HKEY_CURRENT_USER\Software\Interwoven\WorkSite\8.0\Common\General\Portable
though this may be different based on your individual iManage implementation.
If this issue is only occurring on certain documents, one's that are created via a script for example. It may be that the files are zero kilobyte. Have seen this happen before when documents are being dynamically created from sharepoint templates.

Related

Excel form using DTPicker2 control is broken on single machine after moving to Win10

I have an Excel file that contains VBA code and user forms.
One machine has been migrated to Windows 10. The Excel major version hasn't changed though (16). One of the forms lost almost all the controls on it and the user is getting
Compile error: Method or data member not found
at the line Me.cmbWeek.ListCount.
It looks as if this control is not existent in the file on that machine. I wouldn't say it is Windows10 incompatibility as some other machines migrated to Windows 10 flawlessly.
How can I debug what's wrong? The file has worked for years on several machines including the machine of this user (until on Win10). Checked references and there's nothing missing.
The form on user's machine (broken).
The form on on all other users' machines (proper).
I cross-posted to other forums:
excelforum.com
mrexcel.com
ozgrid.com
We managed to trace the problem to the DTPicker2 control on the form. It is part of MSCOMCT2.OCX library. It is present on user's machine, the same as on mine. That machine is version SP4 of the file whereas all other machines have SP6.
I can see that Excel reference points to some other destination than C:\Windows\SYSWOW64 - it points to other app's install path. Probably other app changed something in the registry.
When trying to uncheck the SP4 reference and load SP6 reference I get error
"Can't change references, in use".
Reinstalling office and registering MSCOMCT2.OCX did not help. As it's only two controls causing the issue - or so it seems - I'm now into replacing them with other date picker controls if there are any. If not, I might even use plain textboxes, though it wouldn't be very good solution. Are there any other controls that could handle calendar?
Do check if the region settings on the PC with Win10 the same as on the older PC's.
Changes in date formats, dots vs comma's, etc. can hugely impact VBA's ability to tinker company processes together.

View "$LDAPRDNHier" not updating after adding/editing documents

We have an IBM Domino server running LDAP with an extended user directory. This has worked fine for years but we have suddenly run into an issue with the LDAP failing to find users that are newly added or edited.
Debugging the LDAP service has shown that it looks for users in the "$LDAPRDNHier" view, and we have seen that it works correctly after running a
load updall -R -T $LDAPRDNHier path/to/extendednames.nsf
The view is set to:
Index refresh: "Auto, after first use" (we also tried "Automatic")
Fully indexed (was not indexed but we turned it on while debugging)
The view selection formula does not contain any date specific conditions (this is apparently a cause to this problem)
But we are still having problems.
So far, the only solution we have that updates the view is either:
Manually opening the view in Notes and refreshing it
Running the updall rebuild command specified above
Neither of these solutions are good enough as we need this view to be updated on document change (as it was working previously). No change has been made to this view that caused this to fail.
Any help is greatly appreciated.

Excel TFS Add-In Crashes Connecting to TFS

We frequently use Excel to perform bulk updates of data in TFS. Up until very recently, the Team Foundation Add-In has worked very well. However, it has started failing in several ways:
It will connect to the server, but attempting to connect to any
project causes Excel to crash, producing a Watson report in the
Windows Application Event Log.
If I restart Excel, it reports that it is running into problems with
both the shim and the add-in, and offers to disable it. If I do not
disable it, I still can't connect to a project.
Eventually, the add-in refuses to load at all, until I use the
Options dialog to manually add the COM add-in back into the
application. Doing so produces the same results (Excel crashes when
attempting to load a project).
I have taken the following steps in an attempt to resolve the issue:
Removed and completely reinstalled Office.
Re-registered the add-in component.
Uninstalled and reinstalled Team Foundation Office Integration.
None of these have produced a fix to the issue.
Does anyone know how to resolve this issue?
P.S. If this is not the correct "stack" for this question, kindly point me to the correct one on the exchange. Thank you.
If you are reading the accepted answer and it still isn't working, here's an additional tip. I had the EXACT same problem and saw that same link to clear the cache from numerous sites, bit it didn't work.
Here's the thing. I don't think that article lists ALL of the places that cache can be hiding on your machine. I deleted the cache folder in two different places on my machine and had given up on that as a solution.
Then I searched my entire hard drive for any folder with "Team Foundation" in the name and found a couple more buried in other hierarchies. Deleting these FINALLY solved the problem.
Here are some folders to look for, but like I said, check the entire drive
c:\users\yourlogin\AppData\Local\Microsoft\Team Foundation
c:\Program Files\Common Files\Microsoft shared\Team Foundation Server\
c:\users\yourlogin\AppData\Local\Temp\Microsoft\Team Foundation
The actual cache folder will be nested another level deep under a numbered folder named with something like "7.0" or "8.0" delete the cache folder from every one you find under every number.
In general cleaning the caches on your client machine will resolve such problems, including the TFS and VS caches...
To clean the caches, please see How to clear the TFS cache on client machines

Error on installing any module in DotNetNuke 5.6.3

When I upload any module in System->Extensions in DotNetNuke 5.6.3, running on a Windows 2008 R2 server, IIS 7.5, after the correct module information is displayed and I hit next, I receive the error message
Message: DotNetNuke.Services.Exceptions.PageLoadException: Object reference not set to an instance of an object.. ---> System.NullReferenceException: Object reference not set to an instance of an object.at DotNetNuke.UI.WebControls.FieldEditorControl.CreateEditor()at DotNetNuke.UI.WebControls.FieldEditorControl.DataBind()at
DotNetNuke.UI.WebControls.PropertyEditorControl.AddFields(Table tbl)at
DotNetNuke.UI.WebControls.PropertyEditorControl.CreateEditor()
[...]
and the module is not installed. The file system of the web has not been touched, so I thought it was a permission problem, but even allowing user Everyone to do everything doesn't help (after making sure the ApplicationPoolIdentity user has been allowed full access as well).
Any hint is appreciated.
The manifest of the module is valid (it's Dynamic Registration 4.1).
Update: Installation steps (note: I am using a German installation of Windows 2008, so some translations might not be accurate)
Log in as Hosts Super User (Admin)
Either navigate to System->Extensions or System->Module Definitions (System might be identical to Hosts) - I tried both
In System->Extensions, click Installation assistant for extensions
Select file to upload
Click next
Description of uploading package appears correctly - click next
Error message Object reference not set to an instance of an object. appears on top of the page. Log View shows stack trace as partly displayed above.
What can cause an error in DotNetNuke.UI.WebControls.FieldEditorControl.CreateEditor()?
What kind of permissions could be missing?
Update 2: By step-by-step debugging, I found out that the view state is broken, for some reason. The method BindPackage() in DesktopModules\Admin\Extensions\Install.aspx.vb doesn't find the current Installer Package. I have not yet found out why the viewstate breaks. It is enabled and huge in the rendered page source.
As described in Update 2, the page's viewstate is lost in DesktopModules\Admin\Extensions\Install.aspx.vb. Simply replacing ViewState by Session works (but this workaround may be lost after the next DNN update).
Update (in case someone has a similar issue):
The DNN container that was used had its viewstate turned off! This results in all kinds of weird behaviour, but it took time to track that error. Now it's obvious.

Are there recent Microsoft changes affecting the behavior of AppInitDLLs registry entry?

I support a product that detects unique key combinations when pressed to launch a notification alert.
This monitoring is done by a dll that is injected. Originally this was done specifically to winlogon.exe, but due to some changes in Vista we added the reference to our dll in AppInitDLLs to have it injected into every running process.
This is not working on my newest development machine, and some behavior on client machines mimicks the behavior. Another dll listed, C:\Windows\system32\nvinitx.dll, is still correctly being loaded, but mine is not.
Are there any known recent security patches that may affect this?
there are no new security changes as far as I know, you can inject any dll (but it must be compatible with the process you are injecting into) like if the process is 32bit your dll must be 32 and if the process is 64bit u need to inject 64bit or odd behavior will appear. another things that there is a new bool value must be set in windows 7 (not sure in vista) that is
"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\LoadAppInit_DLLs" must be set to one

Resources