I’m trying to setup Windows Server AppFabric Cache on my local computer. Eventually I get to the point of connecting my C# .NET application to the distributed cache and I get an error. To confirm that the cache is up and running and configured correctly I execute the
“Get-CacheClusterHealth” in PowerShell. When I do this I get the following error:
Get-CacheClusterHealth :
ErrorCode:SubStatus:Failed to connect to hosts
in the cluster At line:1 char:23
+ Get-CacheClusterHealth <<<< -debug
+ CategoryInfo : NotSpecified: (:) [Get-CacheClusterHealth], DataCacheException
+ FullyQualifiedErrorId : Microsoft.ApplicationServer.Caching.DataCacheException,Microsoft.ApplicationServer.Cachi
ng.Commands.GetCacheClusterHealthCommand
I'm installing AppFrabic Cache on a work computer that is attached to a domain. Since I just need a proof-of-concept I'm using XML provider. In the past I have successfully installed AppFabric Cache in other environments, but having issues installing on my local computer.
Since Appfabric Cache is somewhat of a beast to configure, I thought it would be beneficial that I provide the steps I went through to reproduce the issue:
I finally figured it out. After I registered the host using "Register-CacheHost" I should have called "Add-CacheHost".
After I called "Add-CacheHost" I then called "Get-CacheClusterHealth". I finally got the results I expected.
The primary purpose was to create a Proof-Of-Concept in C# that would access AppFabric Cache on a local computer. When I executed the application which was running under my credentials I received the following error:
This is error seems to be a catch-all error. I've seen this error multiple times for different issues.
Since the application was executing with my credentials I needed to give my account permissions to access the cache. It did this by using "Grant-CacheAllowedClientAccount"
Now the cache is working with my application. I was able to get this to work on a computer that was attached to the domain and also to a computer that was in a workgroup.
Related
All the trick seems to be that I'm under AWS.
I found many solutions to solve that problem as connection can be made directly on the server. The issue I have is that I'm running the server on AWS, therefore, only RDP connection is available.
As the server is part of the domain , I added the server as part of the server manager ones on my Domain controller.I tried several times to install/uninstall the RD diagnoser AND the RD License manager. When I try to run each one, I get " Server Manager can not open the tool
Checked with Powershel,, the component install is properly done ( or at list seems to for the system ).
I tried to reset the grace period for RDS server ( info here: https://mangolassi.it/topic/19353/reset-120-day-grace-period-for-windows-rds-server-with-powershell but no effects.
I would need first to get back access to a session, which could be a good start
Thanks for your insights
I've have added my domain account permissions to Windows AppFabric 1.1 Caching using the "grant" Powershell command. A sample app runs locally on the machine itself fine. Also, I'm able to telnet to the port 22233 from another box successfully (I'm pretty sure its not firewall issue).
Could this be IIS permissions somehow? I don't see a site created under IIS. Is there a log I can check to see specifically why the remote calls are getting rejected with a "ErrorCode:SubStatus:There is a temporary failure. Please retry later."
You granted permissions your account to AppFaric Cache, but are you sure that your app runs under this account ? If this is a WebSite, this another user (ApplicationPoolIdentity).
Try to grant your machine (by adding a $ at the end) or run your app under your granted user.
To be sure it is a problem in security, you can try to disable it at server side, just for testing purpose.
Set-CacheClusterSecurity -SecurityMode None -ProtectionLevel None
please find msdn here.
I've installed Web Deploy 2.1 on a Server 2008 R2 running under VMWare.
In the IIS Manager (Management Service applet) I can see that "Enable Remote Connections" is checked and the port is set to 8172. Under "IIS Manager Permissions" I've added my Windows account (CORP\ekkis) and under the "Authentication" applet (for IIS) I have enabled "Windows Authentication".
I've also turned off the firewall.
So from the command line I test the system to work like this:
C:\Program Files\IIS\Microsoft Web Deploy V2>msdeploy -verb:dump -source:contentPath=\temp,wmsvc=192.168.0.70,username=CORP\ekkis,password=MyPass,authType=Basic -allowUntrusted=True
and get this:
Info: Using ID '9b954a0f-ff07-4e77-ba2c-d27472f5fda0' for connections to the rem
ote server.
Error Code: ERROR_USER_UNAUTHORIZED
More Information: Connected to the destination computer ("192.168.0.70") using t
he Web Management Service, but could not authorize. Make sure that you are using
the correct user name and password, that the site you are connecting to exists,
and that the credentials represent a user who has permissions to access the sit
e.
Error: Object of type 'contentPath' and path '\temp' cannot be created.
Error: The remote server returned an error: (401) Unauthorized.
Error count: 1.
I've also tried deploying with Visual Studio 2010 from the host OS with the following service urls (I haven't found proper documentation on how to form this url):
https://192.168.0.70/
https://192.168.0.70:8172/
https://192.168.0.70:8172/MsDeployAgentService/
https://192.168.0.70/MsDeployAgentService/
I've tried the non-secure versions as well but just cannot get it to work. What is the correct format for the url? and what permissions am I missing?
the errors from VS have varied depending on how I attempt it but below is a sample:
Could not complete the request to remote agent URL 'http://192.168.0.70:8172//MSDEPLOYAGENTSERVICE'.
The underlying connection was closed: An unexpected error occurred on a receive.
Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host.
An existing connection was forcibly closed by the remote host
Publish failed to deploy.
there really should be a guide out there to do this (yes, I've googled myself blue in the face)!
thanks - ekkis
ok, I've figured out that the correct url is:
https://192.168.0.70:8172/MsDeploy.axd
and that having the "Windows Authentication" enabled doesn't seem to make a difference. Also, having my account in the "Managers" list doesn't seem to make a difference either.
so the back end was all working fine (I've turned off the Web Deployment Agent Service). it was just the url I had wrong.
I am installing Firebird (v1.5.5 - I know it's old but it works) on a new computer which is running Windows 7. I have installed the classic server version as a service. According to documentation at the Firebird site, I modified the firebird.conf file so that IPCName would be global\FirebirdIPI; I did this while the service was not running.
Despite all my efforts, I have been unable to access any of the databases which I copied to this new computer via ISQL. FWIW, the EMS SQL 2005 manager program is successful in accessing the databases, but this program apparently has a direct method which does not require fbclient.dll.
What else should I be checking?
Update from a few days later. After wasting a great deal of time with Windows 7, we decided to downgrade the computer and run XP. After installing the superserver version of FB 1.5.5, I can run my programs and access the databases which are stored on this computer. Attempts to access the databases from other computers connected on the network failed with a variety of error messages, but normally something like 'i/o error for file !firebird!\db\q400.fdb'.
In order to allow people on the network to continue to access the databases, I revived the NT server and started the Firebird service - and all the programs can access these databases successfully from remote computers!
To simplify matters, there are three computers on the network:
the NT server ('zorcomp'), which is running the Firebird service; the fdb files reside on this computer in a directory called 'db' which sits under a shared directory called 'firebird'
a computer running XP, called 'kivserver', which also has a shared directory called 'firebird' and underneath that a directory called 'programs'. Copies of all the fdb files reside in a directory called 'db'.
a computer running XP, which maps \zorcomp\firebird to disk L: and \kivserver\firebird to disk T. From this computer, I can run a program sitting in T:\programs and get it to access successfully a file sitting in L:\db. If I stop the FB service on zorcomp and start the same service on kivserver, the same program cannot access files sitting in T:\db.
I hope this is clear enough. For the life of me, I can't see any difference between all the files which are residing in \kivserver\firebird to those which are sitting in \zorcomp\firebird - but somehow there is a difference!
Obviously, I don't want this arrangement to continue - the NT server has to be retired honourably.
Further edit. I now have the firebird server running on 'kivserver' (NT). I can access the database files locally.
Computers running Win7 can now access these database files using a connection string \\kivserver\firebird\db\database.fdb.
Computers running XP cannot access these database files, although IIRC wisql did succeed with \\kivserver\firebird\db\database.db.
The NT server has been disconnected from the network.
TIA,
No'am
AFAIK EMS SQL uses fbclient.dll (or a wraper around it).
If the only thing you want is to access the databases, I suggest you to do so using TCP protocol instead of the local protocol. To do it connect like this:
c:\>isql localhost:c:\path\to\db.fdb -u sysdba -p masterkey
Unless you're avoiding TCP or the machine have no local interface enabled, it will do the work for you.
Try using this to connect to your database:
hostname:drive:\complete path\filename.fdb
or
\hostname\drive\complete path\filename.fdb
May I know the component you're using?
If your clients are Windows 7 then you might try to use \\hostname\sharename\filename.fdb instead of drive:\filename.fdb connection string.
Several months later, the NT server was somewhat abruptly retired when it displayed 'MBR error' on rebooting after someone unlugged it by accident. Thus I was left with no option but to start running the Firebird server program on 'kivserver'. The connection problems returned.
Eventually I was able to solve the problem with the following connection string
10.0.0.202:e:\firebird\db\manager.fdb
where 10.0.0.202 is the ip address of the server, and e:\firebird\db the directory in which the database sits, relative to the server itself.
I hope that someone else, some time, will find this information useful.
I have a Windows service written using Topshelf. I'm trying to configure it to run using a Windows account with restricted privileges rather than using LocalSystem. That's also necessary as I'd like to connect to a database using integrated authentication.
The service works when run as LocalSystem (albeit with a database connection string containing credentials) and running the console application as my limited account (using runas) also works.
However, when I try to start the service the service control manager times out waiting for a response:
The service did not respond to the start or control request in a timely fashion.
I also get the following in the Application Popup event log:
Application Error : The exception unknown software exception (0xc06d007e) occurred in the application at location 0x77e4bef7.
The first thing that the application does is writes to a log file but it doesn't reach that when I start the service. The logging works if I run via the console.
Any suggestions what I might be missing or what I might try next?
This problem seems to be related to the server (a domain controller) rather than TopShelf. A service built with the .NET service component also exhibits the same behaviour.
The service runs successfully on a different machine (in the same domain).
Unfortunately this doesn't help diagnose the problem but gives me an acceptable workaround.
Check the MSDN article Debugging windows services which describes how you debug windows services.
I've just started seeing this on a few of my services written in .net 2.0. They'll start fine when the server boots, but if I were to restart them throughout the day, they would not start, and give this error message.
They currently ran under a domain account which has admin rights on the box, but for kicks, I switched it to Local System, and the service started normally. I stopped it, changed it back to the domain account (reentering the password), and it started normally again as expected.
Don't know if this counts as a 'fix' so much, but that's what worked for me.