I have developed a custom snmp extension agent to work in conjunction with Windows Snmp service. I have implemented in C++ using the interface provided by snmp.h from Microsoft and I am creating a 64 bit dll to be used as extension agent.
To install this dll as extension agent I have added a registry under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SNMP\Parameters\ExtensionAgents as:
MyAgent REG_SZ SOFTWARE\MyAgent\CurrentVersion
And under HKEY_LOCAL_MACHINE\SOFTWARE\MyAgent\CurrentVersion, I have created another registry specifying the path of the dll as:
Pathname REG_EXPAND_SZ C:\Program Files\testing\MyAgent.dll
When I did this in the system event logs I keep getting that the The SNMP Service is ignoring extension agent dll C:\Program Files\testing\MyAgent.dll because it is missing or misconfigured.
The agent is a trapless agent. It exposes the SnmpExtensionInit and the SnmpExtensionQuery function from snmp.h. I don't know what is messed up. Do I need a 32 bit dll? All of the sources on internet are very old and refer to Windows NT. I need to configure it on newer operating systems like Windows 10 and Windows server 2016. Any suggestions would help.
Also there are similar questions on SO for same error but all of them are related to migration of a 32 bit dll. I am starting with 64 bit.
because the SNMP process is still 32-bit the key needs to be
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6232Node\MyAgent\CurrentVersion
but I am finding the SnmpExtensionInit is not called
Related
The problem that I have is that after I have built my Unity project using Microsoft's Mixed Reality Toolkit and the Windows SDK 10.0.18362.0 I try to deploy it using the Hololens 2 emulator (version: 10.0.18362.1019). The result is that even though the emulator opens, my Unity application does not get deployed and the following error is being shown in Visual Studio's error list:
Please ensure that target device has developer mode enabled. Could not
obtain a developer license on 192.168.9.57 due to error 80004005
I found several articles online that had the same problem like me, and they either referred to resetting the HoloLens device (which I do not need to do, since it is an emulator) or enabling the Developer Mode on the host machine (in my case a fully updated Windows 10 Enterprise Edition computer), which I already have. Nevertheless the error persists.
I just hope that there will be a way to get rid of this error and manage to deploy my Unity application onto the HoloLens emulator.
It seems that the solution is very simple. If you actually run Visual Studio as an Administrator the application is successfully deployed onto the emulator.
My system has both 32-bit and 64-bit Redshift ODBC drivers installed. It shows up in the ODBC Data Sources under System DSN tab. However, only 32-bit driver shows up in the Drivers tab.
Also, when I attempt to make a Redshift connection by specifying 64-bit in the connection string Driver={Amazon Redshift (x64)}, I get this error: "ERROR [IM002] [Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified".
Only the following in the connection string seems to work Driver={Amazon Redshift (x86)}.
I tried
Re-installing and repairing 64-bit driver.
Removing 32-bit driver from the System DSN tab
But none seemed to work.
Am I missing something?
We had the same problem using the Amazon Redshift driver in our ASP.NET application at our company.
If you're also using the Amazon Redshift driver in an ASP.NET application, I hope what we figured out (the hard way) might help you.
The solution to the problem is to use the 64-bit driver if you're running the application with the 64-bit IIS, and to use the 32-bit driver if you're using the 32-bit IIS. The thing that caught us off guard is that even on a 64-bit machine running 64-bit Visual Studio, the default IIS is 32-bit, not 64-bit. (https://www.jc-tech.info/2016/09/24/running-32-bit-or-64-bit-iis-express/)
This explains why only the 32-bit driver is found by your application. Regarding why the 64-bit driver does not appear in the Drivers tab of the ODBC Data Sources Manager, there are actually 2 versions of the ODBC manager: a 32-bit version, and a 64-bit version. The 64-bit driver will only show up in the 64-bit ODBC manager.
When debugging your application, if you want to make sure that Visual Studio is using the 64-bit IIS, go to Tools>Options>Projects and Solutions>Web Projects, and tick the "Use the 64 bit version of IIS Express" checkbox.
Similarly, when you deploy your application, make sure that your driver version (32 or 64 bit) matches the version of your production environment.
Had same problem,
I kept only 32 bit driver and uninstalled 64-bit and I put
Driver={Amazon Redshift (x86)}.
It worked fine.
More info can be found from below link.
https://social.msdn.microsoft.com/Forums/sqlserver/en-US/480db31c-b583-4c22-a7eb-bc37ad3a3e6d/data-source-name-not-found-and-no-default-driver-specified-error-in-report-builder-when-adding-an?forum=sqlreportingservices
If you are building a .NET application check the project properties for Build option to target x64 platform instead of using Any CPU option to target all
I'm trying to install a legacy VB6 client on a Windows 7 (64-bit) machine that can talk to a DCOM server written in Visual C++. I know I need to run CLIREG32 and pass it the .VBR file as a parameter. I'm trying it like this:
clireg32 myvbrfilehere.vbr -s <ip address> -d -l
It seems to run without a hitch, but I think I should be able to search the registry and see the IP address i entered as a parameter. So something tells me I'm missing something during this command. (I've also tried adding -t mytypelibrary.tlb but that doesn't help either)
Any thoughts on using this ancient technology? I'm not in a position to rebuild everything right now. I'm starting to get desperate...
Thanks
There is at least limited information in Microsoft article Q155939.
(Archived copy.)
Paraphrasing the useful parts:
Q155939: HOWTO: Use Clireg32.exe for Remote Automation
Article: Q155939
Last Modified: 31-JUL-1999
-------------------------------------------------------------------------------
The information in this article applies to:
- Microsoft Visual FoxPro for Windows, versions 5.0, 6.0
-------------------------------------------------------------------------------
SUMMARY
=======
This article provides an explanation of Clireg32.exe and how it is used for
remote automation.
MORE INFORMATION
================
The Clireg32.exe component allows you to register an OLE server (.exe) remotely.
It differs from the Remote Automation Connection Manager (RacMan) in that the
server does not need to be located on the machine registering it. The Setup
Wizard handles the maintenance of registering remote servers for you.
NOTE: Remote servers and Clireg files are stored in the \Windows\Olesrv\
directory, which is similar to Visual Basic if it is installed via the Setup
Wizard.
The Clireg32.exe program takes a number of parameters. The only required one is
the name of the .vbr file (generated with the server during build):
Clireg32 myexesvr.vbr
In order to fully register a remote server, you must provide the network name,
network protocol, and security access. Clireg32 prompts you with a dialog box if
these options are not passed. For a list of all the parameters, simply execute
Clireg32.exe by itself.
Copyright Microsoft Corporation 1986-2002.
I am trying to create a single-sign on connection to a System i server using the example published in IBM's iSeries Telnet Enhancements RFC 4777 within a client telnet app written in C++.
The code sample given calls AcquireCredentialsHandle and then a call to InitializeSecurityContext. The call to InitializeSecurityContext returns an error of SEC_E_TARGET_UNKNOWN, presumably because it does not understand the target name I am passing.
The RFC 4777 says this target name should be a string with kbsrv400 then my server name fully qualified in lower case. I interpretted this as "krbsrv400/iseries.domain.com". I've tried a variety of combinations here but can't get anything to work and not yet found any other code samples that use the MS SSPI API to connect to IBM System i.
I know the Kerberos setup on the System i and domain is working OK as IBM's own iSeries Access is able to login OK and perform a telnet 5250 signon using kerberos.
I am running on Windows 7 signed into a domain. The domain is setup under Active Directory in Windows 2008. I'm using MS Visual Studio 2005 to build my telnet app. The System i server OS is V6R1.
Has anyone got this sample code working?
Any advice on what the format of the target name should be when using it to talk to System i?
Thanks!
Additional info: 9/8/2011
Have got this working OK under Windows XP client with a Windows 2003 managed Domain.
There were two errors in the RFC:
1) It said to use a name of "krbsrv400/spi name" but looking at the ticket in kerbtray that was generated when I logged in using iSeries Access, I saw the actual format was "krbsvr400/spi name".
2) The RFC said to pad the ticket length sent to the system i but when I used Wireshark to look at the IBM iSeries access telnet, I found they did not pad it.
Changing the above got single-signon working OK in my app on Windows XP. I am still experiencing problems on Windows 7.
This is a different domain (managed by the company, and on Windows 2008 and Windows 2003 servers across the world) and with a different iSeries.
Strangely, I can use Kerberos login in System i Access OK, but when I look in kerbtray I do not see a kerbsvr400/... ticket for the system i machine like I do on Windows XP. My app does not work and fails with a SEC_E_TARGET_UNKNOWN error.
My (MS Windows) application can update itself over the internet by download a self extracting archive and launching it via _execv (C++). Now while launching the sfx archive works fine on Windows XP, it doesn't on Windows 7. I guess it has to do with UAC, but even turning UAC off didn't cure this problem. The downloaded sfx archive has the same owner and full access rights as other executables on my computer I can run via _execv. What do I have to do to make this work?
Windows 7 is able to detect installers based on file name and file content and requires additional privilege to start such files. As far as I know Administrator has no such additional privilege. Try to use ShellExecuteEx with runas parameter. It should show you dialog with request for permission to start installer.