Just installed Windows Server AppFabric 1.1 on my Windows 7 box and I'm trying to write some code in a console application against the cache client API as part of an evaluation of AppFabric. My app.config looks like the following:
<configSections>
<section name="dataCacheClient" type="Microsoft.ApplicationServer.Caching.DataCacheClientSection, Microsoft.ApplicationServer.Caching.Core, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" allowLocation="true" allowDefinition="Everywhere" />
</configSections>
<dataCacheClient>
<hosts>
<host name="pa-chouse2" cachePort="22233" />
</hosts>
</dataCacheClient>
I created a new cache and added my domain user account as an allowed client account using the Powershell cmdlet Grant-CacheAllowedClientAccount. I'm creating a new DataCache instance like so:
using (DataCacheFactory cacheFactory = new DataCacheFactory())
{
this.cache = cacheFactory.GetDefaultCache();
}
When I call DataCache.Get, I end up with the following exception:
ErrorCode<ERRCA0017>:SubStatus<ES0006>:There is a temporary failure. Please retry later. (One or more specified cache servers are unavailable, which could be caused by busy network or servers. For on-premises cache clusters, also verify the following conditions. Ensure that security permission has been granted for this client account, and check that the AppFabric Caching Service is allowed through the firewall on all cache hosts. Also the MaxBufferSize on the server must be greater than or equal to the serialized object size sent from the client.)
I'd be very grateful if anyone could point out what I'm missing to get this working.
Finally figured out what my problem was after nearly ripping out what little hair I have left. Initially, I was creating my DataCache like so:
using (DataCacheFactory cacheFactory = new DataCacheFactory())
{
this.cache = cacheFactory.GetDefaultCache();
}
It turns out that DataCache didn't like having the DataCacheFactory created it disposed of. Once I refactored the code so that my DataCacheFactory stayed in scope as long as I needed my DataCache, it worked as expected.
Related
We have different continuous Azure WebJobs (using WebJobs SDK) listening to Azure Service Bus topics which are running across multiple instances on an App Service Environment. Everyday we get multiple log files in the log folder D:\home\LogFiles\kudu\trace containing an exception as below:
<step title="Error occurred" date="2016-12-14T18:26:38.860" instance="qwerty" type="error" text="System.IO.InternalBufferOverflowException: Too many changes at once in directory:D:\home\site\wwwroot\App_Data\jobs\continuous." >
<step title="Cleanup Xml Logs" date="2016-12-14T18:26:38.907" /><!-- duration: 63ms -->
</step><!-- duration: 156ms -->
Is this something to worry about? Is there a way to avoid this exception to happen?
No this isn't something you need to worry about. Our WebJobs infrastructure uses FileSystemWatchers to watch your files for changes (e.g. when job bits/sources are updated, etc.). From time to time due to Azure Storage issues or other network gremlins the file shares that the FileWatcher is connected to might experience transient issues, causing the FileWatcher to throw errors.
We have logic to handle such transient errors (source code here) and we trace them to the log file you pointed out. We log this primarily for our own use to help us monitor/diagnose issues. The logs you mentioned above are coming from this codepath. We have an issue here in our repo to review the verbosity of these traces.
A customer is running one of our programs, usually run as a service, as an application. The customer is getting the following error on CoRegisterClassObject():
The class is configured to run as a security id different from the caller.
It looks like some type of session 0 error, but why should CoRegisterClassObject() care about session 0? COM should allow both services (session 0) and apps (session > 0) and not care what registers what, shouldn't it?
Also, I don't like the fact that it's not in the list of errors returnable by CoRegisterClassObject(), as per the Microsoft doc webpage.
The error code in question is CO_E_WRONG_SERVER_IDENTITY (0x80004015).
Per this page:
COM security frequently asked questions
Q6 Why does CoRegisterClassObject return CO_E_WRONG_SERVER_IDENTITY? When launching my ATL 1.1 server service as an .exe file, I receive CO_E_WRONG_SERVER_IDENTITY from CoRegisterClassObject. (The class is configured to run as a security ID different from the caller.) This seems to occur whether I skip the CoInitializeSecurity or not. It fails running as a service or as an .exe file.
A. Many services are debugged by running them as console applications in the interactive user identity. Because the service is already registered to run in a different identity (configurable by the Services control panel applet), OLE fails the CoRegisterClassObject and RunningObjectTable::Register(ROTFLAGS_ALLOWANYCLIENT) calls by returning CO_E_WRONG_SERVER_IDENTITY to enforce security and to prevent malicious servers from spoofing the server. To debug by running in the interactive user's identity, make the following changes in the server's registry entries to prevent these failures:
• To prevent CoRegisterClassObject failure, remove the following named value:
[HKEY_CLASSES_ROOT\APPID\{0bf52b15-8cab-11cf-8572-00aa00c006cf}]
"LocalService"="HelloOleServerService"
• To prevent a IRunningObjectTable::Register(ROTFLAGS_ALLOWANYCLIENT) failure, follow these steps:
Remove the following named value:
[HKEY_CLASSES_ROOT\APPID\{0bf52b15-8cab-11cf-8572-00aa00c006cf}]
"LocalService"="HelloOleServerService"
Then add the following named value:
[HKEY_CLASSES_ROOT\APPID\{0bf52b15-8cab-11cf-8572-00aa00c006cf}]
"RunAs"="Interactive User"
You muist restore the modified registry entries after debugging.
I am assuming you would have to replace {0bf52b15-8cab-11cf-8572-00aa00c006cf} with your COM object's actual CLSID instead.
Is the Azure Service Fabric Reverse Proxy available in an on-premises cluster? If so, how can I enable it for an existing cluster?
The Service Fabric Reverse Proxy is described here. It allows clients external to the cluster to access application services by name with a special URL, without needing to know the exact host:port on which an instance of the service is running (which may change as services are automatically moved around).
By default the Service Fabric Reverse Proxy does not appear to be enabled for my on-prem cluster with two instances of a stateless service. I tried using the documented port 19008 but could not reach the service using the recommended URI syntax.
To wit, this works:
http://fqdn:20001/api/odata/v1/$metadata
but this does not:
http://fqdn:19008/MyApp/MyService/api/odata/v1/$metadata
In the NodeTypes section of the ClusterConfig JSON used to set up my on-prem cluster, there is a property "httpGatewayEndpointPort": "19080", but that port does not appear to work as a reverse proxy (it is the Service Fabric Explorer web-app endpoint). I am guessing that the needed configuration is specified somehow in the cluster config JSON. There are instructions in the referenced article that explain how to configure the reverse proxy in the cloud, but not on-premises.
What I am looking for are instructions on how to set up the Service Fabric reverse proxy in an on-premises multi-machine cluster or dev cluster.
Yes, the reverse proxy is available on-premises.
To get it working for an existing cluster, it must be configured and enabled in the cluster config XML and then the new config must be deployed, as described below.
For a new cluster, set it up in the cluster config JSON before creating the cluster, as described by #Scott Weldon.
#Senj provided the clue (thanks!) that led me to the answer. I had recently updated my Service Fabric bits on my dev box to 5.1.163.9590. When I looked in C:\SfDevCluster\Data\FabricHostSettings.xml, I noticed the following:
<Section Name="FabricNode">
...
<Parameter Name="NodeVersion" Value="5.1.163.9590:1.0:0" />
...
<Parameter Name="HttpApplicationGatewayListenAddress" Value="19081" />
<Parameter Name="HttpApplicationGatewayProtocol" Value="http" />
...
</Section>
Interesting! With the dev cluster fired up, I browsed to:
http://localhost:19081/MyApp/MyService/api/odata/v1/$metadata
and voila! My API returned the expected data. So #Senj was correct that it has to do with the HttpApplicationGateway settings. I am guessing that in the latest SDK version it is pre-configured and enabled by default. (What threw me off is all the docs refer to port 19008, but the actual configured port was 19081!)
In order to get the reverse proxy to work on the 'real' multi-machine (VM) cluster, I did the following (Note: I don't think upgrading the cluster codepackage was necessary, but since I had nothing in my image store for the cluster upgrade, and the cluster upgrade process requires a code package, I used the latest version):
Copy the existing cluster manifest (from the Manifest tab in Service Fabric Explorer), paste into a new XML file, bump the version number and modify as follows:
To the NodeType Endpoints section, add:
<NodeTypes>
<NodeType Name="NodeType0">
<Endpoints>
<HttpApplicationGatewayEndpoint Port="19081" Protocol="http" />
...
</Endpoints>
</NodeType>
</NodeTypes>
and under <FabricSettings>, add the following section:
<Section Name="ApplicationGateway/Http">
<Parameter Name="IsEnabled" Value="true" />
</Section>
Using Service Fabric PowerShell commands:
Copy the new cluster config (the previously copied manifest.xml) to the fabric image store
Register the new cluster config
Copy the Service Fabric Runtime cluster codepackage (available here - see the release notes for the link to the MSI) to the image store
Register the cluster codepackage
Start and complete cluster upgrade (I used unmonitored manual mode, which does one VM at a time and requires a manual Resume command after each node is complete)
After the cluster upgrade was complete, I was able to query my service API using the reverse proxy endpoint and appname/servicename URL syntax:
http://fqdn:19081/MyApp/MyService/api/odata/v1/$metadata
I enabled this in the standalone installer version (5.1.156) by adding the following line to the JSON configuration file under the nodeTypes element (I used ClusterConfig.Unsecure.MultiMachine.json but I assume any of the JSON files would work):
"httpApplicationGatewayEndpointPort": "19081"
So the final nodeTypes looked like this:
"nodeTypes": [
{
"name": "NodeType0",
"clientConnectionEndpointPort": "19000",
"clusterConnectionEndpoint": "19001",
"httpGatewayEndpointPort": "19080",
"httpApplicationGatewayEndpointPort": "19081",
"applicationPorts": {
"startPort": "20001",
"endPort": "20031"
},
"ephemeralPorts": {
"startPort": "20032",
"endPort": "20062"
},
"isPrimary": true
}
]
I think it has something to do with the HttpApplicationGatewayEndpoint property, see also my question on https://github.com/Azure/service-fabric-issues/issues/5
But it doesn't work for me..
Also notice that
<Section Name="ApplicationGateway/Http">
<Parameter Name="IsEnabled" Value="true" />
</Section>
is true for me.
Edit:
I noticed that on my Windows-Only installation, HttpApplicationGatewayListenAddress has value 0 in the FabricHostSettings.xml
<Parameter Name="HttpGatewayListenAddress" Value="19080" />
<Parameter Name="HttpGatewayProtocol" Value="http" />
<Parameter Name="HttpApplicationGatewayListenAddress" Value="0" />
<Parameter Name="HttpApplicationGatewayProtocol" Value="" />
There's something that's not very clear to me and does not show up in the documentation:
After successfully setting up a Cache Cluster with 2 hosts, what is the address for connecting to this cluster? I know this screams setting up a Windows Cluster all over but I just wanted to make sure there wasnt anything I'm missing.
Not sure I understood your question. The default port to connect to on of your cluster nodes is 22233. Here is an example. You can build up the connection within the code or by putting the cache host configuration into your Web.config file.
There is no 'address' as such, as you might expect in a load-balancing scenario, but you specify host(s) in the hosts section of the dataCacheClient config element:
<dataCacheClient … >
<hosts>
<host name="server1.mydomain.local" cachePort="22233" />
<host name="server2.mydomain.local" cachePort="22233" />
</hosts>
</dataCacheClient>
I have install Virtual Machine Manager on windows server 2012 R2 . it installed sucessfuly but the SCVMM service can't be started please check the following log for and the error
when i try to start SCVMM service its endup with the following error
" The System Center Virtual Machine Manager Service on Local Computer started and then stopped. Some services stop automatically if they are not in use by other services or programs.
"
Log Name: Application
Source: SCVMMService
Date: 11/4/2014 7:58:55 AM
Event ID: 0
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: HC**********
Description:
Service cannot be started. System.Reflection.ReflectionTypeLoadException: Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.
at System.Reflection.RuntimeModule.GetTypes(RuntimeModule module)
at System.Reflection.RuntimeModule.GetTypes()
at System.Reflection.Assembly.GetTypes()
at Microsoft.VirtualManager.Remoting.IndigoSerializableObject.BuildKnownAssemblyTypes(Assembly assembly)
at Microsoft.VirtualManager.Remoting.IndigoSerializableObject.InitializeKnownTypesCache(List`1 assembliesToExamine)
at Microsoft.VirtualManager.Engine.Remoting.IndigoServiceHost.InitializeKnownTypesCache()
at Microsoft.VirtualManager.Engine.VirtualManagerService.TimeStartupMethod(String description, TimedStartupMethod methodToTime)
at Microsoft.VirtualManager.Engine.VirtualManagerService.OnStart(String[] args)
at System.ServiceProcess.ServiceBase.ServiceQueuedMainCallback(Object state)
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="SCVMMService" />
<EventID Qualifiers="0">0</EventID>
<Level>2</Level>
<Task>0</Task>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2014-11-04T07:58:55.000000000Z" />
<EventRecordID>10656</EventRecordID>
<Channel>Application</Channel>
<Computer>HC-S*********** </Computer>
<Security />
</System>
<EventData>
<Data>Service cannot be started. System.Reflection.ReflectionTypeLoadException: Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.
at System.Reflection.RuntimeModule.GetTypes(RuntimeModule module)
at System.Reflection.RuntimeModule.GetTypes()
at System.Reflection.Assembly.GetTypes()
at Microsoft.VirtualManager.Remoting.IndigoSerializableObject.BuildKnownAssemblyTypes(Assembly assembly)
at Microsoft.VirtualManager.Remoting.IndigoSerializableObject.InitializeKnownTypesCache(List`1 assembliesToExamine)
at Microsoft.VirtualManager.Engine.Remoting.IndigoServiceHost.InitializeKnownTypesCache()
at Microsoft.VirtualManager.Engine.VirtualManagerService.TimeStartupMethod(String description, TimedStartupMethod methodToTime)
at Microsoft.VirtualManager.Engine.VirtualManagerService.OnStart(String[] args)
at System.ServiceProcess.ServiceBase.ServiceQueuedMainCallback(Object state)</Data>
</EventData>
</Event>
Thanks for posting here.
To resolve this issue, review the AD group membership for any circular references and remove them. If the circular reference is not obvious, the script below can list the nested members of a particular group.
NOTE Use Active Directory Users and Computers to determine the top most group of the group causing issues.
dsquery group -name "Group_VMMSSU" | dsget group -members -expand
I hope you have followed these steps before installing SCVMM
High Level Deployment Process:
In AD, create the following accounts and groups, according to your naming convention:
•DOMAIN\scvmmsvc SCVMM Service Account account
•DOMAIN\scvmmadmin SCVMM RunAs account for managing hosts
•DOMAIN\sqlsvc SQL service account
•DOMAIN\SCVMMAdmins SCVMM Administrators security group
Add the “scvmmsvc” and “scvmmadmin” account to the “SCVMMAdmins” global group.
Add the domain user accounts for yourself and your team to the SCVMMAdmins group.
I suggest you to check this link for more details.
http://blogs.technet.com/b/kevinholman/archive/2013/10/18/scvmm-2012-r2-quickstart-deployment-guide.aspx
Girish Prajwal
I had this error and couldn't find an updated answer to the problem.
In my case, I have SCVMM (server AND console) installed on the same machine (i guess this is pretty normal for a first time installation).
I had seen the system working, then I installed all updates offered from Windows Update. After reboot, my service "System Center Virtual Machine Manager" could not start.
Solution was to look in control panel: "Programs and Features". Clicking "installed updates" there was an entry for System Center Console.
This was a rollup 10.
I uninstalled this, now the service is able to start, and I can log on.
Hope this helps someone.
This KB article from Microsoft addresses the issue- https://support.microsoft.com/en-us/kb/3045931
To resolve this issue, complete the update rollup installation by installing the VMM server update package in addition to the console update. Both the VMM server and VMM Admin Console updates must be at compatible version levels. This will typically be the same update rollup level. For example, a VMM Admin Console should be at the VMM UR5 level if the server is also at UR5.
In some instances, there may not be a comparable update for a component. In that case, the component should be updated to the most recent applicable update. For example, if the VMM server is updated to a post-UR5 hotfix, but there is no corresponding hotfix for the VMM Admin Console, the VMM Admin Console should be updated to UR5.
In my case update rollup 11 was the cause for the break. Going in to Programs and Features -> Installed Updates, I noticed that Update rollup 11 for the admin console had installed successfully but Update rollup 11 for the VMM service had failed.
I manually installed the failed update (in my case http://download.microsoft.com/download/7/5/1/7515E3DB-1B43-4E7F-8774-A877CCEAA96E/kb3184831_vmmserver_amd64.msp) and now VMM service is able to start and stay started.