Local Security Authority LabView 2024 Q3

[josborne]

Can anyone confirm that renaming (instead of deleting) makes this problem go away?

I can't seem to replicate this issue.  But lots of my customers are reporting it.  

My solution will be to run a batch file at the end of my installer which renames the file (in ProgFiles and also ProgFilesx86).  Since the installer runs with Administrator privileges, I am hoping this will solve the problem.

[Darren]

---

@josborne wrote:

Can anyone confirm that renaming (instead of deleting) makes this problem go away?

---

I'm also unable to reproduce the security prompt locally, so I can't confirm that renaming is a workaround. Hopefully someone else on this thread can?

[_Bryan]

---

@josborne wrote:

Can anyone confirm that renaming (instead of deleting) makes this problem go away?

I can't seem to replicate this issue.  But lots of my customers are reporting it.  

My solution will be to run a batch file at the end of my installer which renames the file (in ProgFiles and also ProgFilesx86).  Since the installer runs with Administrator privileges, I am hoping this will solve the problem.

---

I can't confirm yet.

Yesterday I uninstalled all the NI software and reinstalled with admin privileges and the message did not immediately pop up, so I thought I was good.  But later in the day I remotely logged into the machine and it had the same error again.  Since I could not delete the files I sent an email to our IT to delete the files locally for me.  (I think this was before it was mentioned to rename them)  IT could only find the dll in the Program Files directory and could not delete it, but was able to rename it.

I remoted into the machine this morning and confirmed the renamed file and that the dll was no longer in the x86 directory.  I am still working on the machine so I can check on it throughout the day to see if it happens again.  I am not really sure why or how the file in the x86 path was removed, unless it was deleted and I was only focusing on the file that I could not delete.

A side note, I emailed support about this on Monday and they are still going through have you tried to install with admin privileges and ask your IT department about it.  So I figured it would not hurt to point them to this discussion.

[Frozen]

---

@Darren wrote:

---

@josborne wrote:

Can anyone confirm that renaming (instead of deleting) makes this problem go away?

---

I'm also unable to reproduce the security prompt locally, so I can't confirm that renaming is a workaround. Hopefully someone else on this thread can?

---

I have change the dll back to normal to see if the pop up re-occurs. It can take some time for the pop up to appear so I will let you know if it comes back.

And when I say "rename", I simply add ".BAK" to the file name so "nimdnsNSP.dll" become "nimdnsNSP.dll.BAK". Of course, you will get the two Windows pop up warnings about the "file might become unusable" and the lack of admin permissions to make the change.

Aaaannd it is back, even before I finished typing this. LOL

EDIT: BTW, I only changed the one file in <C:\Program Files\National Instruments\Shared\mDNS Responder> since the pop-up specifically calls out the path.

[Basilgeuse]

I am unsure how much effort anyone here wants to put into resolving this issue, but I recently needed to package NI ElvisMX for my environment, and was running into this error at the end of installation.

The main issue is that there is no certificate associated with the .dll file in question. LSA Device Guard is a bit more strict on Windows 11, and doesn't like when unsigned modules are attempted to run.

My solution was to create my own certificate and self-sign the certificate to the .dll file. Afterwards, I imported the certificate from my personal store, to the Trusted Publishers store.

After running a test installation and verifying the error no longer appears, I exported the signed certificate, added it to my package in Intune, and just wrote out a script that installs the certificate to the local machine in the trusted publishers store before installing the application.

[rolfk]

---

@Basilgeuse wrote:

I am unsure how much effort anyone here wants to put into resolving this issue, but I recently needed to package NI ElvisMX for my environment, and was running into this error at the end of installation.

The main issue is that there is no certificate associated with the .dll file in question. LSA Device Guard is a bit more strict on Windows 11, and doesn't like when unsigned modules are attempted to run.

My solution was to create my own certificate and self-sign the certificate to the .dll file. Afterwards, I imported the certificate from my personal store, to the Trusted Publishers store.

After running a test installation and verifying the error no longer appears, I exported the signed certificate, added it to my package in Intune, and just wrote out a script that installs the certificate to the local machine in the trusted publishers store before installing the application.

---

Aside from NI properly signing all their DLLs, this is the solution that will fix it for sure for the very zealous virus scanners. Unfortunately that is not enough for kernel device drivers. Microsoft not only wants them to be signed, but they have to be signed with an Extended Verification certificate, send in to their developer center to have them counter signed with the Microsoft Certificate and only then will Windows consider the device driver a valid binary.