Some background info, I am evaluating on Clearcase, and I have setup my environment like this:
Clearcase server (VOB and View servers) installed on my Windows XP
Clearcase client installed in the virtual machine on the same XP, with bridged network
I used Common Licensing
The problem I am facing is, I can get license on my server XP, but not on my client virtual XP, the following error is returned:
File path: C:\Program Files\IBM\RationalRLKS\common............27000#<my host name>;
FLEXnet Licensing error:-96,491
Some sources suggested about specifying the vendor daemon port, but I have no idea how to check what is the current daemon port and how to change it, anyone has idea?
More information about FLEXnet Licensing error:-18,147
cleartool: Error: License checkout error from Rational Common Licensing:
The FEATURE name RLPwCC with version 1.0 cannot be found
License server system does not support this feature.
Feature: RLPwCC
License path: C:\Program Files\IBM\RationalRLKS\common\rational_perm.dat;C:\Program Files
\IBM\RationalRLKS\common\rational_temp.dat;27000#<my host name>;
FLEXnet Licensing error:-18,147
For further information, refer to the FLEXnet Licensing documentation,
available at "www.flexerasoftware.com".
cleartool: Error: You do not have a license to run ClearCase.
For evaluation purpose, I would recommend asking IBM for a simple file for Atria licensing, instead of having to start a Flexlm server.
But if you have a FlexNet license key, you can see the technote "Resolving FLEXnet Licensing Error: -96, 491" (for Telelogic, but you can adapt it for ClearCase).
To assign a specific port to the Telelogic DAEMON, (example: 19354) add the string " PORT=19354 " at the end of the VENDOR line in the license file.
For example:
VENDOR telelogic "C:\Program Files\Telelogic\Tools\Licensing_11\Server\telelogic.exe" PORT=19354
Ensure that the port 19354 (or whichever port number you have chosen to specify) is open for bi-directional communication by the Firewall.
You can use any bi-directionally open port as a fixed port for the Telelogic vendor daemon, so long as the port is not being used by any other application.
The OP Arthas Tsang reports then having the error:
FLEXnet Licensing error:-18,147
The actual cause is generally mentioned after that part, as for example illustrated in the technote "FLEXlm error: 18,147 is reported if RLPwCC licenses are in use and ClearCase commands are run from a non-root cron job" (if your ClearCase isn't started with admin privileges)
Regarding "The FEATURE name RLPwCC with version 1.0 cannot be found", many messages state an issue with the installation of the license server (like this thread)
Problem Solved after installing the Latest Version of the License Server.
Check this technote to get just the License server.
Regarding the "System clock setback detected", this technote mentions several causes:
If there is a Server / Client setup then the most likely cause of the error is a discrepancy in the time/date between the server and the other machines in the network.
Resolution.
Cause 2: The system on which the licenses are set up has been Back Dated.
Cause 3: If there are files present on the OS that are dated past the current date.
(See also this technote)
And the OP Arthas Tsang does report it was indeed a time-stamp issue:
I finally found two files, neither of them related to FlexLM, with timestamps marked in 2014.
After removing those files, the license works fine.
Related
When I want to create the tables to after see the preview of my job appears this error:
error: GeneXus C# Generator:
local protection:
Not authorized
Default (C# Web) Generation Failed
error: Error in reorganization
Run Developer Menu Failed
It appears that you don´t have an authorization for the .NET (C#) generator.
If you look at GeneXus License Manager, is it authorized or not?
Check out this page for more information.
The message speaks of local license so another possibility would be that you have installed your licenses remotely and the License Manager pointing locally as you see in http://www.gxopen.com/forumsr/servlet/viewthread?ARTECH,3,158064
If this is the case proceed as follows:
Open the Genexus License Manager and set there the license of the c # generator pointing to the remote machine by name or IP.-
It should also take into account a series of requirements which I do not detail in depth as it would be too long.
These requirements vary depending on whether the pc server is in the same domain or in the same workgroup as the local pc.-
In particular you should keep in mind things like:
a) Firewall with its exceptions on port 135 (DCom) and for
ProtSrv.exe application
b) User with Remote Access premition for anonymous loggin
c) Updated DNS
For more information about that last point plese see http://wiki.genexus.com/commwiki/servlet/wiki?19985,Setting+user+permissions+using+remote+licenses,
How do I resolve this issue with requests to msmdpump.dll for connections to SQL Server Analysis Services? I am receiving a 500 Error from the IsapiModule.
On a Windows Server 2012 R2 machine, with IIS 8.5, I have setup the OLAP data pump (msmdpump.dll), using the following instructions: https://msdn.microsoft.com/en-us/library/gg492140.aspx#bkmk_copy
The application pool is configured for .NET CLR v4.0, with Classic Managed pipeline mode. The identity is set to a local service account. (I have also tried a domain account, and I have tried making the local user an Administrator).
I've created an application under the Default Web Site, called OLAP, with an IsapiModule, as per the MSDN article.
As far as I can tell (and I've double and triple checked), everything is configured as laid out in the MSDN article. Also, compared to another server where I have this setup (on a different network), it is essentially the same.
When I request http://localhost/OLAP/msmdpump.dll in a browser on that machine, I receive a 500 Internal Server Error. The error indicates that it is trying to use the OLAP handler that I created. This is not the same error that I would normally expect when doing a GET request to msmdpump.dll. The normal error for a straight GET, when everything is working correctly, is sent back in a SOAP envelope. In my case, the request does not appear to ever be processed by msmdpump.dll.
500 Internal Server Error via browser:
(see below for full screenshot)
Module IsapiModule
Notification ExecuteRequestHandler
Handler OLAP
Error Code 0x8007007e
Requested URL http://localhost:80/OLAP/msmdpump.dll
Physical Path C:\inetpub\wwwroot\OLAP\msmdpump.dll
Logon Method Anonymous
Logon User Anonymous
500 Internal Server Error via SSMS connection:
I also receive an error when trying to connect to the data pump via SQL Server Management Studio:
Screenshot of the 500 error in the browser:
One appreciable difference between the machine I'm setting up, and the server where the data pump already works, is that there are a few more roles setup on the new server.
The problem server includes:
.NET Extensibility 4.5
ASP.NET 4.5
While the other machine (where the data pump works), does not include those roles. Would the presence of ASP.NET 4.5 or .NET Extensibility 4.5 cause an issue with IIS serving requests for this IsapiModule?
Quick answer
In my case installing KB3138367 (https://support.microsoft.com/en-us/help/3138367/update-for-visual-c-2013-and-visual-c-redistributable-package) resolved the issue.
Longer answer
There are a few debugging steps that can be useful.
Configure IIS tracing
For full instructions see: https://learn.microsoft.com/en-us/iis/troubleshoot/using-failed-request-tracing/troubleshooting-failed-requests-using-tracing-in-iis
However, you can ignore the parts where it tells you to delete your existing content - they're going a little overboard there to ensure you get the same results in the tutorial. Just add the failed request tracing to your existing site, catching "500" status codes.
In my case, that led me to the result:
ModuleName IsapiModule
Notification EXECUTE_REQUEST_HANDLER
HttpStatus 500
HttpReason Internal Server Error
HttpSubStatus 0
ErrorCode The specified module could not be found. (0x8007007e)
I confirmed that my handler mappings had the correct path to msmdpump.dll, but still got the error. So time for the next debugging step:
Use Sysinternal Process Monitor to check w3wp.exe
Process monitor is a free tool from Microsoft: https://learn.microsoft.com/en-us/sysinternals/downloads/procmon
Use Process Monitor to log file system access (filter on the "w3wp.exe" process to avoid being overwhelmed)
Look for NAME NOT FOUND and PROCESS NOT FOUND results. There will be a number of these as the system attempts to e.g. locate various dlls, so it is normal to see some NOT FOUND results followed by SUCCESS results for the same filename. You are looking for NOT FOUND results that do not have any corresponding SUCCESS results.
In my case, this highlighted two dlls:
msvcr120.dll
msvcp120.dll
These turn out to be part of the “Microsoft Visual C++ 2013 Redistributable” package (https://superuser.com/questions/1163409/msvcp120-dll-and-msvcr120-dll-are-missing).
However, "Add/Remove Programs" showed that the package was already installed. Running "repair" on the package did not resolve the issue.
Locating the dlls
In my case, the OLAP pump is installed an a web server separate from Analysis Services.
Running these powershell commands:
Get-ChildItem -Path 'C:\' -Recurse -File -Filter 'msvcr120.dll' -ErrorAction SilentlyContinue | select -ExpandProperty DirectoryName
Get-ChildItem -Path 'C:\' -Recurse -File -Filter 'msvcp120.dll' -ErrorAction SilentlyContinue | select -ExpandProperty DirectoryName
yielded some interesting results. On the web server, the dlls only showed in C:\Windows\SysWOW64.
However, on the server where Analysis Services was installed, the dlls were present in both C:\Windows\System32 and C:\Windows\SysWOW64 (as well as a few other sql server paths)
(as an aside, SysWOW64 contains 32 bit dlls, and System32 may contain 64 bit dlls. So simply copying from SysWOW64 to System32 is likely to cause you problems. See https://www.howtogeek.com/326509/whats-the-difference-between-the-system32-and-syswow64-folders-in-windows)
I could see from the Process Monitor logs on the web server that one of the search paths was C:\Windows\System32. A little more searching led to KB3138367 (Installing both Visual Studio 2013 Redistributable packages (x86 & x64) at the same time)
The actual KB text (https://support.microsoft.com/en-us/help/3138367/update-for-visual-c-2013-and-visual-c-redistributable-package) describes the issue:
When you install an updated redistributable package, binaries for
non-target architectures are removed. For example, after you install
an update for an x86-based application, the x64 Visual C++ 2013
runtime libraries are missing. This fix makes sure that both versions
of the Visual C++ redistributable are visible when you add or remove
programs after installation of the update.
You should probably disable Anonymous Authentication on IIS
This is the perfect article, as expected to see on stackoverflow! I even thought that this case is also mine, but thorough checks shown my problem was crushing msmdpump.dll, and that crash was an exception, caught internally by msmdpump.dll. The only visible clue was a message in Windows Application log stating "an internal error happened" (or smth. alike). Googling alot didn't bring any valuable results, but suddenly this article gave me an idea to check for the LATEST MSQL cumulative update from here, and, after installing it and re-coping msmdpump.dll the crash was gone and cubes finally shown up as expected in SSMS interface. Needless to say that all issues with IIS Identity Pool, double-hop and other security-related stuff was rechecked many times with no success... Realizing that exception is inside the dll itself take some time to come...
I have hosted my WebApp on server 1 and my database on server 2
But I'm getting following error
Communication with the underlying transaction manager has failed.
I googled and found a post which mentioned that it is the issue of DTC(Distributed Transaction)
I enabled DTC on server2(DB server) and made an exception of it in Firewall.
But still same error.
Here is the full stack trace
Message: System.Transactions.TransactionManagerCommunicationException: Communication with the underlying transaction manager has failed. ---> System.Runtime.InteropServices.COMException: The MSDTC transaction manager was unable to pull the transaction from the source transaction manager due to communication problems. Possible causes are: a firewall is present and it doesn't have an exception for the MSDTC process, the two machines cannot find each other by their NetBIOS names, or the support for network transactions is not enabled for one of the two transaction managers. (Exception from HRESULT: 0x8004D02B)
at System.Transactions.Oletx.IDtcProxyShimFactory.ReceiveTransaction(UInt32 propgationTokenSize, Byte[] propgationToken, IntPtr managedIdentifier, Guid& transactionIdentifier, OletxTransactionIsolationLevel& isolationLevel, ITransactionShim& transactionShim)
at System.Transactions.TransactionInterop.GetOletxTransactionFromTransmitterPropigationToken(Byte[] propagationToken)
Kindly advice
We had the exact same situation, and more than once. Each time, it was one of the following:
The IP address in the DNS for the server is outdated (as said in error message: "two machines cannot find each other by their NetBIOS names"). You can check if this is the case by trying ping servername from one server to another in the command prompt. If the ping by name fails and ping by IP succeeds (or ping by name returns the wrong IP), than you should talk to the System Admins to take a look at DNS/DHCP.
The servers are created as an image of preconfigured server (for example, if you are working with virtual machines, and instead of doing a fresh install for each of the servers, you simply clone the image). This is a problem because DTC has an internal "Identifier" - and in case of image cloning both your installations now have same DTC ID, and won't be able to communicate with each other. The solution is to simply uninstall and install the DTC again.
Hope it helps.
Things to check:
Have you done this configuration on both servers?
Are both servers members of the same domain?
Have you checked the event log?
I had the same problem while connecting to a remote SQl Server.
The solution in my case was to add "enlist=false" to the connection string.
I was missing quite a lot of things:
No authentication (as DB server and APP server and not within same AD domain)
Rule to Windows Firewall enabling msdtc.exe
Rule to firewall between DMZ and internal zone TCP 135,1024-65535 in both directions. The link tell you how to restrict the firewall policy to few ports only.
short / long server names to hosts or a shared DNS server. Eg. 192.168.1.1 app1 as well as 192.168.1.1 app1.domain.local
On the other hand based on this link my setup doesn't require:
Allow Remote Clients
Allow Remote Administration
Enable XA Transactions (required prior Windows Server 2003 SP1)
Solved after adding remote IP\machine name to files on server:
hosts, lmhosts
in folder
C:\Windows\System32\drivers\etc
One of our servers displayed this error after the Virtual Machine (VM) controlling our Domain Controller froze. Several related communication problems also started to pop up (like failed password resets). Resetting the frozen VM fixed the issue.
Lots of helpful answers already given.
One problem for me was the presence of invalid (cyrillic) characters in the computer name.
And there is also a way to validate the connection between two servers (or between a server and a computer) using a small tool from Microsoft called DTCPing.
I built a D2010 application, which uses a TADOConnection component to connect to SQL Server using OLEDB drivers and tcp/ip. The problem is that my application can't connect to the database when I execute it (inside the IDE or not) from a network drive. Each time I try i get this error through the IDE:
---------------------------
Debugger Exception Notification
---------------------------
Project TroisTiers.exe raised exception class EOleException with message '[DBNETLIB][ConnectionOpen (Connect()).]SQL Server does not exist or access denied.'
---------------------------
Break Continue Help
---------------------------
and I get a "EOleException: Unspecified error" when I run the application outside the IDE.
The thing is, When I copy the .exe on a local drive (C:) it works instantly, no errors, no lag. When I compile the D2010 application on a WinXP computer and execute it from Win7, it also works flawlessly. When I take the .exe I builded and execute it on a x86 Windows 7, I get the same errors as above.
I noticed that when I start the application on the network drive, the following modules are loading:
Module Load: WSHTCPIP.dll. No Debug Info. Base Address: $74CD0000. Process TroisTiers.exe (848)
Module Load: WSHIP6.dll. No Debug Info. Base Address: $74010000. Process TroisTiers.exe (848)
Module Load: DBnmpntw.dll. No Debug Info. Base Address: $750C0000. Process TroisTiers.exe (848)
I have asserted that the app tries to connect using TCP/IP first, then for whatever reason resorts to named pipes. Just for tests, I activated the named pipes protocol on the server and it started to work but not every time and takes up to 10 seconds before the connection is made. I deactivated it since it's not the way we connect to the production databases. When the app is executed locally (and showing data correctly), the DBnmpntw.dll module is neved loaded.
When I build a connection string (through a .udl file) and test the connection, it works, though I am not certain if I'm testing through the 64bit or 32bit drivers.
Setting the .exe output directory to my local drive is an acceptable work-around for now but I would really like to know what's causing this problem, as it makes things complicated with working in an up-to-date environment (additionnal files beside the .exe).
Additionnal info, for what it's worth:
My connection string: 'Provider=SQLOLEDB.1;Persist Security Info=True;User ID=*;Password=hunter2;Initial Catalog=[database name];Data Source=[server ip address]'.
I tried to force using TCP/IP with "Network Library=DBMSSOCN;" but it doesn't help.
Firewalls disabled on my computer and on the server;
McAfee AV on my computer, managed through ePO;
SQL Server 2005 x64 running on Win2k3 x64;
Windows 7 without SP1 installed;
cliconfg.exe -> active protocol is tcp/ip only;
I can provide additionnal info if needed.
Is your .EXE too large for running on a network shared drive? I have the same experience when the size of .EXE exceed 25MB or something closed to.
The solution is simple, just to move the .EXE back to local drive.
All,
After several months of not touching our databases I fired up Rapid SQL and get this error when I try and connect to a registered Sybase DB:
"Layer (5) Origin (3), Severity (5), Number (3) ct_connect(): network_packet_layer: internal net library error: Unable to find an available protocol driver structure"
Any ideas? I'm running on a corporate desktop build so always possible that drivers and software are changed/installed etc every time I log on.
Thanks in advance
Ensure that the Sybase System/Environment variable points to the latest version of sybase.
Rename an old Sybase installs to Old-Sybase12 etc.
Remove any old Sybase directories from your path.
Make sure your path contains the latest Sybase dirs.
Should do it.