I'm trying to enable MSMQ on my development computer (running Windows 7).
I go to turn windows features on or off -> Microsoft Message Queue (MSMQ) Server Core -> Check MSMQ Active Directory Domain Services Integration AND MSMQ HTTP Support.
When I click OK, I get the error "An Error has occurred. Not all of the features were successfully changed." -> Click OK -> "You must restart your computer to apply these changes".
I've clicked Restart Now and Restart later and no matter what, same issue every time.
If I selected Restart later and go into Services...I see Message Queuing (stopped), and if I try to start the service, I get the error "Windows could not start the Message Queuing service on Local Computer. Error 0x80070005: Access denied."
I checked my privileges and I am an Admin on the machine. Just to be safe, I even logged into the machine as the actual Administrator. Same scenario.
Furthermore, when I go into the Event Viewer, I check the Application logs. I have an error with MSMQ as the Source. EventID: 2076, Error: The logger files cannot be initialized. The file QMLog in the Msmq\Storage folder is corrupted or absent. Error 0x80070005: Access denied.
If I check the System Logs, I see another error with the source being Service Control manager. Error eventId: 7023, Error: The Message Queuing service terminated with the following error: %%-2147024891
When I look up the error codes on Microsoft, there is NOTHING.
I had something like this - not sure how it came about as I always had AD integration turned ON for my MSMQ (as I needed it) but somewhere along the line, it got turned off and I couldn't turn it back on again via Control Panel - I would get the error behaviour (and restart!) that the OP describes. To fix it, I accessed my machine via the AD services manager app on one of our domain servers and deleted the "msmq" object that was under it.
I restarted my local MSMQ service on my machine AND rebooted (not sure which or both was required) and then when I checked my local registry entries, it indicated I was correctly running in AD mode once again. Everything started to work again after that.
This link was helpful in giving me the right direction to go in: Technet MSMQ delete stale objects article
Related
I have a BizTalk 2013r2 Standard Edition application server with CU7 installed. The BizTalk databases are hosted on a separate Sql Server 2014 server. This setup has been working fine for many months - until today! A colleague used the BizTalk admin console to make a change to the address BizTalk uses to the reach the SMTP server, by selecting Platform Settings\Adapters\SMTP\\properties.
After making this change, on attempting to refresh the BizTalk Admin Console, the following error is displayed:
From what I've googled, it seems this may be due to some corruption in the SSO database. I have a backup of the SSO database, and a backup of the SSO key along with the password. Before restoring the backup of the SSO database, I wanted to check that I would be able to restore the key, so I ran ssoconfig -restoreSecret from the command line. I was prompted to enter the password. If I intentionally enter the wrong password then it tells me the password is incorrect. However, if I enter the correct password then it displays the message "BAD DATA".
Although the BizTalk admin console is currently unusable, thankfully the BizTalk host instance continue to run and messages are being processed as expected.
Can anyone please suggest why I'm getting the "BAD DATA" message, or perhaps a work-around in order to solve the problem?
I had this problem again and blogged about it at BizTalk WinMgt error solution. As Colin says the hard part is identifying the corrupt handler. It is probably the SMTP send handler but you should check this using WBEMTEST first. I found this link helpful on using WBEMTest. The parameter is incorrect (WinMgt)" error when refreshing the BizTalk Group in BizTalk Administration Console
In my case a quick fix to bring the BizTalk Administration Console back to life was to hack the database. N.B. This probably won't be supported by MS. In my case it was the FTP send handler that screwed up. So I ran
USE [BizTalkMgmtDb]
GO
DECLARE #return_value int
EXEC #return_value = [dbo].[adm_SendHandler2_Delete]
#AdapterName = N'FTP',
#HostName = N'Sending32'
SELECT 'Return Value' = #return_value
GO
At this point the BizTalk Administration console came back to life. In my case it worked because I was creating a new handler but in your case you just edited it. It will take all your SMTP handling out.
I then fixed the corruption using the BizTalk Administration console.
In my case I had to set every FTP receive and send adapter temporarily to a FILE adapter.
I then deleted the FTP adapter and then re-added it. Finally I reset the all the change receive and send location from FILE back to FTP.
This was all very scary on a live system.
Finally I believe that this is bug in BizTalk 2013 R2 because I've seen it happen on 2 systems and now I have heard that the same thing happened to you.
The WinMgt error happens when one of the Adapters setting has gotten itself corrupted. See WinMgt error when refreshing Group Hub
Removing and re-adding the adapter to the host usually fixes it. The trick of course is identifying which Adapter / Host, I would start with the SMTP adapter in your case.
I'm trying to deploy an application via web deploy to a windows 2012 r2 server.
First tried installing iis, web deploy using the msi. After getting an unreachable error I saw somewhere that I needed wmsvc to be installed and installed it via powershell command Install-WindowsFeature Web-Mgmt-Service.
I stopped getting the unreachable error and started getting this error ->
Error: Could not complete the request to remote agent URL 'http://xx.x.xx.xx:8172/MSDEPLOYAGENTSERVICE'.
Error: The operation has timed out
On the server's event viewer under system I get the following error ->
A fatal alert was generated and sent to the remote endpoint. This may result in termination of the connection. The TLS protocol defined fatal error code is 10. The Windows SChannel error state is 1203.
Any idea of what could be going on? Did I miss something on the installation?
After this I also tried installing everything but without iis and I get the same error.
So, this is really not a PoSH issue.
Maybe you should consider movin gthis question to another forum.
Anyway, you have either real server config issues (this can sometimes mean wipe and rebuild - very ugly option - but if it's a virtual machine and you have a snapshot, just roll back), or an app causing this.
Typically for Schannel type of error, it has to do with application or service in machine not able to complete any SSL connection sort of connection.
The error state parameter of 1203 means client error connecting to server, ie invalid ClientHello from the client
See if you can collect more data by...
https://support.microsoft.com/en-us/help/260729/how-to-enable-schannel-event-logging-in-iis
I realized this is an old question, but in case somebody ran into the same issue, here are my solution.
I had to follow this guidelines : https://learn.microsoft.com/en-us/aspnet/web-forms/overview/deployment/configuring-server-environments-for-web-deployment/configuring-a-web-server-for-web-deploy-publishing-web-deploy-handler
Copy the resulting publishsetting file. In the Publish/Profile page import it.
In the Publish/Connection page, change the server to the server address with the 8172 port. Add the password. Change the Destination URL to the site to go to after the publish is completed.
Then after Validate connection was completed, go ahead and publish it!
Yesterday our extracts failed to refresh with the following message (image extract_error):
Failure: Failed 1 time. Sign in failed.
Resolution Details: Check the Data Connection page for necessary updates to an access token or embedded credentials.
I verified that all our passwords were unchanged and test connections which were successful.
The tableau dashboards now give an error message saying:
HTTP 404:
Unable to connect to the server "localhost". Check that the server is running and that you have access privileges to the requested database. (image tableau_error)
Further, when I opened the Server Status page, I saw that our one of our two Vizql, backgrounder and data servers were down. We have two of each and only one of them is active for all three of them. (image server_status)
So, I decided to remote desktop into the server and run the tabadmin status -v command and strangely it is showing that all processes are running. (image tabadmin_status)
Finally, I opened a case with Tableau Customer Portal and letting them know about this issue (they asked me send them the log.zip file) but the mean time I was trying to problem solve this issue. Any help would be really appreciated.
After trying a lot of things, one process seemed to work.
Stopped the tableau server
Configured it to run 1 Vizql server process instead of 2
Started the server again
Finally, it worked. The status page now shows all the processes are active.
Hopefully, this helps someone who is facing a similar problem.
This may be caused by a firewall issue. Since tabadmin status -v returned all as "running" the cluster is healthy and this is a false alert. The firewall rules could be allowing just the first port and not the entire range (see https://onlinehelp.tableau.com/current/server/en-us/ports.htm) to respond to requests from the application server to build that fancy table with the green and red boxes.
The firewall can be reverted/altered behind the scenes for a number of reasons, usually windows updates or regular group policy synchronization.
Try disabling the windows firewall (https://www.faqforge.com/windows-server-2016/turn-off-firewall-windows-server-2016/), or add an inbound rule allowing access to all ports if your org policy doesn't allow you to actually turn it off. (Follow the steps here, except use "All Local Ports" instead of "Specific Local Ports" https://www.parallels.com/blogs/ras/configuring-windows-server-firewall-for-parallels-ras/)
I had a similar problem and followed these similar steps that Sravee mentioned above to bring the all processes back to active.
Stopped the server
Change the configuration for VizQL server from 2 to 1
Started the server
Enter the licence key (else the server status page will show unlicensed error)
Note: This does not bring the site back but this step is for 'tricking' VizQL server
Stopped the server again
Change the VizQL configuration from 1 to 2 now.
Start the server
Enter the license key
This steps did bring back the server back to active for us. Posting to see if this helps who faces the same problem. Thank you so much.
I'm trying to get the list of available queues on the remote machine. The machine is a Win2003R2 in Workgroup mode, and the client machine that runs the code is a Windows 8 machine both using the same Workgroup name. I get an exception when running the following code:
var messages = MessageQueue.GetPrivateQueuesByMachine("Win2003SRV");
And the error message is:
base {System.Runtime.InteropServices.ExternalException}: {"Access to Message Queuing system is denied."}
Message: "Access to Message Queuing system is denied."
MessageQueueErrorCode: AccessDenied
I'm pretty sure it has something to do with permissions on Windows 2003 but couldn't find much. The code works fine with another Win Server 2008 (but in workgroup mode) and works with local MSMQ as well. According to the MSDN page, this function is supported on Workgroup mode, so what's the catch?
SOLVED:
My issue turned out to be that I didn't have MSMQ installed on my Client machine! The help on the link pointed me to the right direction, so all I had to do was to install MSMQ on client machine as well. If you look at the implementation of GetPrivateQueuesByMachine, the native call can throw a DllNotFoundException and it is that exception that translates into that specific message, so it should give you a hint on what is wrong
John Breakwell who is/was a msmq MVP has a few posts which may help. The problem seems to be caused because the GetPrivateQueuesByMachine() method uses RPC under the hood to communicate between queue managers on different machines.
http://blogs.msdn.com/b/johnbreakwell/archive/2010/03/24/understanding-how-msmq-security-blocks-rpc-traffic.aspx
There is a public queue named queue1 on machine A. I want to send messages to this queue from machine B. In order to achieve this, I wrote that c# code.
if (MessageQueue.Exists("machineA\queue1"))
{
label1.Text = "queue found";
}
else
{
label1.Text = "queue could not be found";
}
But Exists() method return false on machine B. The same code works well on machine C.
I found somethings related with msmq domain mode and workgroup mode. I think that msmq installed in workgoup mode on machine B.
How can I change this configuration from workgroup mode to domain mode?
HKEY_LOCAL_MACHINE\Software\Microsoft\MSMQ\Parameters\
Check the data for the REG_DWORD workgroup. Is it 1 or 0?
1 is workgroup mode.
0 is AD mode
Basically the difference between domain and work group mode is not defined by the value of the registry flag "workgroup" mentioned by #engin. This flag just reflects current operational mode but doesn't set it.
Whether you run in domain or workgroup mode is defined whether you installed MSMQ on domain controller or on a member server. Details about differences between these two modes can be found here: https://support.microsoft.com/en-us/kb/884974/
MSMQ 1.0 used to support domain mode only. Current MSMQ version is 5.0.
Next you may see quite interesting behavior when you installed MSMQ on your DC, your workgroup flag continuously reverts to 1 after each MSMQ service restart. This means that you have to grant Network Service account the Create MSMQ Configuration Objects permission to the computer object in Active Directory Domain Services before installing the Directory Services Integration feature on a computer that is a domain controller.
You may find details on how to do it here:
https://technet.microsoft.com/en-us/library/cc730960.aspx
MSMQ runs under the (less privileged) Network Service account instead of (all powerful) Local System account starting from version 4.0 (Vista/Server 2008)
So to answer #mkus question more directly to "set" domain mode you just install MSMQ on domain controller and make sure that proper permissions in place for Network Service account. Once this is done you well see it operating in domain mode with workgroup flag switched to 0 automatically to reflect this.
Also couple of links to clarify issues around MSMQ objects permissions and when/why you need to set them:
http://blogs.msdn.com/b/johnbreakwell/archive/2009/08/03/default-msmq-queue-permissions-have-changed-in-msmq-4-0.aspx. In short starting from MSMQ 4.0 Everyone and Anonymous Logon were removed from default MSMQ objects ACLs as precaution against DoS attacks (though there are exlusions to this change and Workgroup mode is one of those).
And as you may read in Technet article below you need to go a grant certain rigts to MSMQ objects either to Network Service OR to Computer accounts when installing the Routing Service feature on a Windows Server 2008 R2 (or later) computer that is not a domain controller OR when installing the Directory Service Integration feature of Message Queuing on a Windows Server 2008 R2 (or later) computer that is a domain controller. See details here:
https://technet.microsoft.com/en-us/library/cc749102(v=ws.10).aspx
Run Server Manager on the machine that is hosting the queue. Right-click on Features and click "add features"
Drill down under Message Queuing and under Message Queuing Services. You should see a checkbox for Directory Service Integration.
Check it and click install.
Usually you have to reboot the server for it to show the change.
I ran into some problems, no matter how much I installed or uninstalled MSMQ or restarted, I still wasn't able to use the queue. So I wanted to post some links here
http://support.microsoft.com/kb/935498
When it gets to a part about "To work around this problem, use the Active Directory Users and Computer Microsoft Management Console (MMC)...". Below is how you do that.
How to delete from active directory
http://technet.microsoft.com/en-us/library/cc773660(v=WS.10).aspx
"Delete stale computer objects" is the part you are interested in.
I also found this nice error in the event log "The Message Queuing service will not join the domain. An MSMQ Configuration (msmq) object exists in the new domain with an ID differing from the service ID. Please delete the MSMQ Configuration object in the new domain, restart the Message Queuing service, and log on again."- which helped to point out they way.
I have face this issue for windows server 2016, where even thought I was changing registry value to domain mode "0", it reverts to "1", after server restart.
To solve the issue on OS 2016, we need to uninstall below MSMQ feature as they are deprecated from OS 2016 onward.
Message Queuing Trigger
Multicasting support
Routing Service