In our company, we got a fully running, and healthy, SCCM enviroment.
Every component in "Site Status" and "Component Status" is looking good and green, and everything is working as intended, BUT..
Idk if this is a issue at all, but its annoying my eyes, and its questioning, WHY does the server not delete expired updates (Updates marked with black X) when running the scheduled synchronization?
I checked the box "Remove obsolete updates from the WSUS database"
The SUP Component Properties:
SUP Component Properties
The log:
wsyncmgr.log
I already checked all running components and wsus related logs, everything seems to run great.
Related
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
I've got this question. Yesterday I was working in my SSIS project without any problem. In one of the task I have created a connection to one Oracle database. Everything was working perfect. Just to clarify, the project is hosted in a PC that is never switch off because there are some scheduled tasks that run very late at night.
But today, when I tried to run the package again I've get the following message:
Connection Management 'name' is working off line.
I tried to test the connection again but I could get any answer from the Oracle database. However from other PC's there is no problem with this connection.
What could be happening? or, what else is necessary to do in order to keep the connection working?
Right click on the connection manager and uncheck the option of "Work offline" or something of that sort.
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.)
It's the concern about Admin console's performance from Websphere Application Server.
I can login smoothly without any problem, but it's got be very slow on response when doing operations such as showing Node status by clicking "Nodes" under "System administration", showing AppServer status by clicking "Application Servers" under "Servers" etc. However, the funny thing is the problem is more serious on remote node than the local nodes which locate on same box with DmgrNode.
So i suspect it should be the problem with network communication between DmgrNode and remote Node, but i don't know how to fix it.
Anybody got the same issue here??? Or any idea to figure it out? Please do me a favor, please please .......
When the console gets the list of servers to display, it does make mbean calls to all of the servers, and if there is a network problem between the dmgr and the node, this could cause some delay in displaying the server page. The nodes page, however, should not have that issue. What is your topology? How many nodes/servers and how many are local/remote?
How can you tell the problem is more serious on the remote nodes than the local nodes?
Are other console operations slower, or only ones that display status? Do you have the same problem with wsadmin commands? The console issues a queryNames to search for the server mbeans. Does the following wsadmin command run much more slowly on the remote node than the local node? If so, how much more slowly?
print AdminControl.queryNames('WebSphere:type=Server,node=myNode')
Replace myNode with either the local or remote node name.
I assume you are using IE to fire up the console. Fire the console from Chrome and see if it helps.
Background:
I am using the deployment tools in Visual Studio 2010.
I right clicked my project and selected Package/Publish settings. Put all my settings in there ...
I am then using "web deploy" to tranfer the files to my remote server running a remote agent service and this is working fine. The transforms i have on my Web.Release.config do their thing and the server can access the database I created manually.
Problem:
My next step was to get the Database Deployment working too.
I went into the Package / Publish SQL tab and entered my Connection string for the destination database.
(Data Source=MyDBServer;Initial Catalog=Database2;User ID=User;Password=pass)
This database is empty ready to accept the import.
I also enter in the connection string for the source database. This lives on the same server.
(Data Source=MyDBServer;Initial Catalog=Database;User ID=User;Password=pass)
Database Scripting options are set to Schema and Data (changing this makes no difference) and the database scripts are set to [Auto Generated Schema and Data]
When i deploy this now, i get the error:
Error 4 Web deployment task
failed.((09/06/2010 16:41:51) An error
occurred when the request was
processed on the remote computer.)
(09/06/2010 16:41:51) An error
occurred when the request was
processed on the remote computer. The
entry type 'Unknown' was not expected
at this time. The serialization stream
may be corrupted.
Additional Info:
I can successfully create a package with no problems. I looked at the contents in the zip and can see the SQL is generated fine (so no problems connecting to the database). I can then copy this SQL and run it as a new query on the new database and the tables and data are created fine.
I can not seem to work out where this is going wrong, i googled the error and there are no entries on the whole internet. Anyone have any ideas?
Addendum:
To get some further idea of what might be going on, i sent the package across to the server and imported it using IIS. It told me i needed SQL Server Management Objects. So I installed that.
Next attempt it told me my user did not have permission to create the database, I thought excellent this must be the problem. :Granted access - Re-run. Passed!
So i deleted all the tables and went back to VS2010 clicked publish and i get the same error. :(
Sorted it!
Thank goodness, i was totally out of ideas when i went back to a video by hanselman. He mentioned that the Web Deployment Agent can have permissions. I went in had a look and there was a tab in it's properties called log on.
I entered the detials of an account with a decent level of access and clicked okay.
I then restarted the service as requested to enable the changes.
I then went back to VS 2010 and clicked Publish Web.
Music to my eyes, i see the words "Publish succeeded", I check the database and the tables are there. Excellent!
I think i scared the office by getting a little over excited, if you get this problem and this solution fixes it for you, try to hold in the temptation to shout out "YES!, yes, get in!" while laughing maniacally or people will think you're weird like me.