I recently started using OMS. I have installed the MMA agent on both on-prem DC's. There is no on-prem SCCM.
On the console is says to AD Replication Status | "No Data Found" | Click here to troubleshoot. When it pushes through to the next page I get status on the 2 servers that have MMA installed Both indicate a message of "Computer meets all requirements to be a valid assessment target."
I don't see or have any data for AD Replication status.
I have tried various search sites but it seems that the problem may be so new I can't find any information specifically on this problem.
I've attached a couple of images for clarification.
results saying valid assess target
Related
I'm looking into ways of replicating databases from On-Premise environments to Azure and one of the options I found was setting up a Read-Scale availability group.
The reason I'm using a Read-Scale and not an Always On availability group, is because I don't won't to use SQL Server Enterprise edition due to the cost.
I followed a tutorial from Microsoft (MS TUTORIAL) to set this all up and in the end, I think I got it working as my database appeared on the Azure environment.
However, the problem is that my replica always stays in the Synchronizing state - which is probably due to the fact I chose Asynchronous Replication by using the AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT command - but even worse is that I can't access the database itself.
Each time I try to fire a query against it, it comes back with an Object is not accessible exception.
After some reading, I found that the cause of this might be because my replica doesn't have a secondary role. Trying to set this via the ... SECONDARY_ROLE({ALLOW_CONNECTIONS = ALL})... command, clearly states that this feature is not available in the Standard version of SQL Server.
My whole confusion comes from the fact that on the Microsoft documentation (MS DOCS), it says that With availability groups, one or more secondary replicas can be configured to support read-only access to secondary databases. which is exactly what I'm not succeeding in.
Did anybody have the same issue, or knows how to configure the Read-Scale availability group on SQL Server Standard so my second replica is accessible and readable as well?
P.S. I did look at the actual SQL Replication with Transaction Replication, but there are quite a bit of moving parts there, so I'm exploring all options before making a decision.
Based on a twitter conversation I found out that you will need to create a snapshot of the database in Secondary Replica in order to read from there.
Please read this tweeter thread.
I also added a suggestion in the feedback channel to fix the documentation.
Application: http://localhost:1080/webTours/home.html [I intend to use it for Jmeter testing]
Below error is displayed when I am trying to click on "sign up now" link. Kindly help to fix it. Pls note, I have strawberry-perl-5.30.0.1-64bit.msi also installed and path is set to the environment.
Internal Server Error The server encountered an internal error or
misconfiguration and was unable to complete your request.
Please contact the server administrator, admin#localhost and inform
them of the time the error occurred, and anything you might have done
that may have caused the error.
More information about this error may be available in the server error
log.
Thanks.
Probably, you need to do the correlation for the dynamic parameters like sessionID etc.
Record two scripts using tools like fiddler or LR or any other sniffing tool and compare two scripts to find out dynamic variables required. Then correlate them. For correlation, identify the first occurrence of the variable in the response then extract them using post processor and pass them further below/to all the request that requires it.
Hope this helps.
It appears that your Web Tours Sample Application installation is broken, looking into MICRO FOCUS SUPPORTED stanza in the application details you should contact Micro Focus Support or ask the question in Micro Focus Community Forums.
In the meantime you can use http://blazedemo.com/ page and Getting Started with JMeter - A Basic Tutorial as the alternative test application for your JMeter training
If you are not getting internal server error while sign up (or) accessing administration link then follow the below,
a. close the server from the cmd
b. In the Web Tours 1.0 parent folder, find the file .msi file: strawberry-perl-5.10.1.0
c. Double click on strawberry-perl-5.10.1.0 msi file to install
d. Once it is installed, Now re-start the server (Double click on StartServer.bat file) under WebTours sub-folder
e. Now, Go to link http://localhost:1080/webtours/home.html
f. Click on Sign up (or) administration link
g. Hope you are able to access the Web Tours app in local server now. Thanks! :-)
In odoo v10 Enterprise while trying to sync bank accounts for auto feed entries then getting following error.
Once your bank accounts are registered, you will be able to access your statements from the Accounting Dashboard. The available methods for synchronization are as follows.
Direct connection to your bank
Importing your statements in via a supported file format (QIF, OFX,
CODA or CSV format)
Manually enter your transactions using our fast recording interface
I would like to go with first one "Direct connection to your bank"
In that I am facing issue so I want to fix it.
Issue :
Problem Updating Account(507):We're sorry, Yodlee has just started providing data updates for this site, and it may take a few days to be
successful as we get started. Please try again later.
I recently removed 2 sharepoint servers from a 4 server farm and I get the following errors:
This Distributed Cache host may cause cache reliability;
More Cache hosts are running in this deployment than are registered with SharePoint.
Both errors are referring to the two removed servers.
The cache cluster shows only the 2 remaining servers as cache hosts.
I re-provisioned Distributed Cache, but I still get the error.
Also tried everything listed here.
Any thoughts?
Taken from here: http://alstechtips.blogspot.com/2015/02/sharepoint-2013-this-distributed-cache.html
First, get the ID of the Distributed Cache Service Instance (with PowerShell).
Make sure you edit the following command to add your WFE server name.
Get-SPServiceInstance | Where-Object {$_.Server -Like "*<yourWFE>*"} | Select-Object TypeName, ID, Status | Sort-Object TypeName
Look for Distributed Cache in this listing, and copy its ID, then edit this command to include the ID:
(Get-SPServiceInstance <yourWFE-ID>).delete()
Then finally:
Remove-SPDistributedCacheServiceInstance
Reanalysing the alert should show it disappear (fixed).
It's then up to you to decide whether you want to deploy another Distributed Cache Service Instance.
I removed the errors from Sharepoint "Review problems and solutions" and ran the rules again. Errors did not show the second time.
I went to deploy over an existing Cloud Service (in staging) and received the following message:
"Error: No deployments were found. Http Status Code: NotFound"
Does anyone know what this means?
I am looking at the Cloud Service, and it surely exists.
UPDATE:
Been using the same deploy method as prior (successful) efforts. However, I simply right click the cloud service in Visual Studio 2013. In the Windows Azure Publish Summary, I set to: the correct cloud service name, to staging, to realease ... and press publish. Nothing special really...which is why I am perplexed
You may have exceeded the maximum number of cores allowed on your Azure subscription. Either remove unneeded deployments or ask Microsoft to increase the maximum allowed cores on your Azure subscription.
Since I had this problem and none of the answers above were the cause... I had to dig a little bit more. The RoleName specified in the Role tag must of course match the one in the EndpointAcl tag.
<Role name="TheRoleName">
<Instances count="1" />
</Role>
<NetworkConfiguration>
<AccessControls>
<AccessControl name="ac-name-1">
<Rule action="deny" description="TheWorld" order="100" remoteSubnet="0.0.0.0/32" />
</AccessControl>
</AccessControls>
<EndpointAcls>
<EndpointAcl role="TheRoleName" endPoint="HTTP" accessControl="ac-name-1" />
<EndpointAcl role="TheRoleName" endPoint="HTTPS" accessControl="ac-name-1" />
</EndpointAcls>
</NetworkConfiguration>
UPDATE
It seems that the previous situation is not the only one causing this error.
I ran into it again now due to a related but still different mismatch.
In the file ServiceDefinition.csdef the <WebRole name="TheRoleName" vmsize="Standard_D1"> tag must have a vmsize that exists (of course!) but according to Microsoft here (https://azure.microsoft.com/en-us/documentation/articles/cloud-services-sizes-specs/) the value Standard_D1_v2 should also be accepted.
At the moment it was causing this same error... once I removed the _v2 it worked fine.
Conclusion: everytime something is wrong in the Azure cfgs this error message might come along... it is then necessary to find out where it came from.
Just to add some info.
The same occured to me, my WM Size was setted to a size that was "Wrong".
I have multiple subscriptions, I was pointing one of them, and using a machine "D2", I don't know what happened, the information was refreshed and this machine disappeared as an option. I then selected "Large" (old), and worked well.
Lost 6 hours trying to upload this #$%#$% package.
I think the problem can be related to any VM Size problem
I hit this problem after resizing my role from small to extra-small. I still had the Local Storage set to the default of 20GB, which an extra-small instance can't hold. I ended up reducing it to 100MB and the deployment worked (the role I'm deploying is in maintenance mode only for a couple of months, so I don't care much about getting diagnostics from it).
A quick tip: I was getting nowhere debugging this with Visual Studio's error message. On a whim, I switched to the azure website and manually uploaded the package. That finally gave me a useful error: that VM size was too small for the resources I had requested.
I encountered this error during the initial deployment of a Cloud Service that required a specific SSL Certificate... that was missing from Azure.
Corrected the certificate - deploy succeeded.
(After the first deployment Visual Studio provides a meaningful error in this case.)