MSMQ on a domain controller defaults to workgroup mode, how to switch to Domain mode? - windows-server-2008

I have a Windows Server 2008 machine acting as Domain Controller for a test domain and I have installed MSMQ on this server including the "Message Queue Server", "Directory Services Integration" and "Message Queueing Triggers" features. I've also installed MSMQ onto a second machine in the domain that is running Server 2003.
The install on the domain controller apears to default to workgroup mode, theres no Public Queues options and attempting to programatically create one results in a message "A workgroup installation computer does not support this operation". The install on thw 2k3 server defaults to Domain mode complete with Public Queues support.
Can anyone give me instructions on how to get MSMQ working in Domain mode on the Domain Controller?

Turns out I got the permissions in the AD a little wrong when installing MSMQ. Removing MSMQ setting the right permissions and reinstalling the queue fixed the problem.

Related

RabbitMQ Management Plugin

I am having some issues accessing the rabbitmq_management plugin.
I am running RabbitMQ 3.6.2, where rabbit is installed as a service and the plugin is enabled. Running on Windows Microsoft Server 2012.
Service runs fine, no errors in logs, however when i try and access the management tool via the web browser UI, "This page can't be displayed", I am sure i am going to the right port as the logs show the port it is running on, i have tried adding some rules to the Inbound on the firewall in case it was to do with ports and nothing seems to work. Any ideas?
EDIT
I am able to access the port via another machine on the network but does still not work in local host.

Publishing a MVC App in Azure Web App

This is my Azure configuration:
I have a Virtual Network with a couple of subnets and a gateway
configured to allow point-to-site.
There is one Virtual Machine with SQL Server (2014) installed. There
are some databases in there already. SQL Server is set up to allow
SQL Server and Windows Authentication mode. This VM is in the Virtual Network
I have an empty Azure Web App
I deployed my main MVC WebApp to the empty Azure Web App and looks good, except when it tries to retrieve information from the database.
Is it a connection string error? or there can be something else...
My connection string looks like this:
<add name="MyEntities" connectionString="metadata=res://*/Data.MyModel.csdl| res://*/Data.MyModel.ssdl| res://*/Data.MyModel.msl;provider=System.Data.SqlClient;
provider connection string="
data source=tcp:10.0.1.4;
initial catalog=MyDataBase;
persist security info=False;
user id=MySystemAdmin;
password=SystemAdminPassword;
multipleactiveresultsets=True;
App=EntityFramework""
providerName="System.Data.EntityClient" />
Here is the error thrown by the azure web app...
So it seems to be related to either the way I'm providing the connection string or the end-points/firewall configuration.
Check your connection string against this connection string for Entity Framework designer files (https://msdn.microsoft.com/en-us/data/jj556606.aspx#Connection)
Just from a quick glance I see two possible errors:
Semicolon missing added after provider=System.Data.SqlClient (the example on the page I provided the link to doesn't have one)
The IP address you specify to connect to is a local one (10.0.0.1) and should be the IP/DNS name of your database in Azure.
Not sure if this is the issue or if StackOverflow just clobbered your markup. In addition you talk about a lot of gateways so I would check to make sure you can talk between your systems. Finally posting error messages and capturing exceptions about what's actually going on will help diagnose the error because at this point it's all guesswork.
Hope that helps.
What the guys said above plus:
The Web App needs to have a hybrid connection to the VNET the VM is if you want to use the local IP address, otherwise you have to use the PIP.
Check the firewall on the VM if the proper ports are open. This has to be both on the VM firewall and the endpoints. Also, if there are any ACLs on the VM, you have to check those too.
The other answers gave me the guidelines to find out the solution.
I'll try to describe the steps I followed:
Using the new azure portal (portal.azure.com currently in preview) I
established a connection between the Azure Web App and the Virtual
network:
Home > Browse > Click on Azure Web App name
In the Azure Web App blade click on Networking tile
In Virtual Network blade, click on the Virtual Network where the database is located (it's important to mention that the Virtual Network ought to have a gateway previously configured)
My intention was to provide certain level of security to the VM with
the databases by placing it inside a Virtual Network, so I had not
considered opening ports. Turns out that it's necessary, so, in the VM:
I enabled the TCP/IP protocol for SQL Server using the Sql Server Configuration Manager (How to? here)
Then I created a new Inbound Rule opening the 1433 port, but only for private connections (very nice).
It was not necessary to create an endpoint in the VM for this port (very happy with this).
Finally, I published the the app to the Azure Web App using the connection strings as shown in the question (with internal database IP)
Final touch: in the new Azure Portal > Azure Web App > Settings, I was able to enter Connection Strings. Settings created in the portal are not overwritten; so now I'm sure this Azure Web App will always use the correct connection string.
Final note: in theory (not tested yet) the internal IP will not change as long as the VM is not Stopped (Deallocated).

Error configuring using Windows Service Bus (1.1) Configuration Wizard

I am trying to configure Windows Service Bus (1.1) using Service Bus Configuration Wizard. I am getting below error when I try to configure it. Can anybody tell me what is the problem.
[Error] [5/9/2014 9:32:40 AM]: System.Management.Automation.CmdletInvocationException: Starting service Service Bus Gateway on machine USHP2-10-056A failed: Time out has expired and the operation has not been completed. ---> Microsoft.ServiceBus.Commands.Common.Exceptions.OperationFailedException: Starting service Service Bus Gateway on machine USHP2-10-056A failed: Time out has expired and the operation has not been completed. ---> System.ServiceProcess.TimeoutException: Time out has expired and the operation has not been completed.
Please see below for Configuration Information of Service Bus
Management Database SQL Instance USHP2-10-056A\SQLSERVER2012SP1
Enable SSL connection with SQL Server instance False
Authentication Windows Authentication
Management Database Name SbManagementDB
Gateway Database SQL Instance USHP2-10-056A\SQLSERVER2012SP1
Enable SSL connection with SQL Server instance False
Authentication Windows Authentication
Gateway Database Name SbGatewayDatabase
Message Container SQL Instance USHP2-10-056A\SQLSERVER2012SP1
Enable SSL connection with SQL Server instance False
Authentication Windows Authentication
Message Container Database Name SBMessageContainer01
RunAs Account gopalac-c#HERBALIFECORP
RunAs Password *******
Certificate Generation Key ******* (Gopala123)
Farm Certificate Auto-generated
Encryption Certificate Auto-generated
HTTPS Port 9355
TCP Port 9354
Message Broker Port 9356
Resource Provider HTTPS Port 9359
Amqp Port 5672
Amqps Port 5671
Internal Communication Port Range 9000 - 9004
Enable firewall rules on this computer True
Administrators Group BUILTIN\Administrators
Registering container databases SBMessageContainer01 SBMessageContainer02
SBMessageContainer03
Creating Namespace ServiceBusDefaultNamespace
Management Portal Admin User adminUser
Management Portal Tenant User tenantUser
Look in \Windows\System32\drivers\etc and edit the hosts file - In my case I noticed that I had localhost defined more than once. Even though they were all set to 127.0.0.1 it still seems to have confused the Service Bus config.
I removed the duplicates and then it worked.
I lost 2 days on this.
My issue.
I had previously (months before) installed and was running RabbitMQ.
This guy gave me the hint:
http://www.khalidabuhakmeh.com/installing-windows-service-bus
Make sure you uninstall all previous versions of the Windows App Fabric on your development machine. Additionally, disable any
windows service that utilizes the AMQP protocol (RabbitMQ). If you do
not disable RabbitMQ then the Service Bus will not be able to start
up. Finally, make sure you have SQL Server Express 2012 installed.
In regards to SQL Server, make sure to enable TCP/IP protocol; this
can be done using the SQL Server Configuration Manager tool.
Once I stopped all RabbitMQ service, I was able to complete the installation.
Sidenote : I used a domain-account. I was connected to my domain-network while doing the install. I did not try with a local-account after I got my issue resolved.
========================================================
Other links I found along the way (besides this one).
http://developers.de/blogs/damir_dobric/archive/2012/09/18/servicebus-message-broker-service-is-starting-and-starting.aspx
https://github.com/matthewcanty/Microsoft.Cloud.Common.AzureStorage.FAKE.dll
http://curtisbadke.ca/blog/2015/10/18/fun-with-installing-service-bus-for-windows/
Things you’ll need to be aware of for local Service Bus installation:
If you are in a workgroup you must use local users, if you are in a domain you must use domain users. If you are on Windows 10 with an
AAD user your machine is probably in a workgroup. reference
If you have VS 2015, you need to install a fake Microsoft.Cloud.Common.AzureStorage assembly.
You must use Nuget package WindowsAzure.ServiceBus 2.1.4.0 or older.
You must address your Service Bus connections using your full machine name not a short name or something like localhost
Hopefully this saves someone hours of frustration
I got it working with the following procedure:
before install
(https://social.msdn.microsoft.com/Forums/en-US/688ada3c-bb95-488d-9ad0-aec297438e1c/problem-starting-message-broker-during-service-broker-configuration?forum=servbus)
Open configuration Wizard and select "Leave Farm"
Delete all the Service Bus related databases in SQL server
Uninstall Service Bus 1.0 and Windows Fabric
Remove the folder 'C:\ProgramData\Windows Fabric' if it exists
Remove the folders 'C:\Program Files\Service Bus' and 'C:\Program Files\Windows Fabric' if it exists
Reinstall the product:
Run "Microsoft.ServiceBus.ConfigWizard.exe" as admin (right-click 'run as admin')
Choose 'with custom settings'
Set the 'Internal communication port range' to any unused port (not the default 9000, which is often used)

Getting MSDN PeerChannel "SecureChat" running on Windows Server 2008 R2

I can only get this SDK sample of PeerChannel SecureChat to work in the following scenarios in a basic home network:
Locally among instances running on the same machine, or
Among Windows 7 machines
I cannot get this to work between my Windows Server 2008 R2 and any other machine (no exceptions are thrown, but the nodes never find each other and thus don't go "online"). I CAN ping the IPv6 addresses among all machines. The executable has a firewall exception rule, but I have also tried disabling the Windows 2008 firewall completely. The PRNP Service is running.
Is it possible to get it working? How?
Does it work on YOUR 2008 machine?
My best guess: I notice that in the Windows 7 machines, the "Peer Networking Grouping" and "Peer Networking Identity Manager" services are present. The "Peer Networking Grouping" service's description there and online talks specifically about enabling multi-party conversations, but related to Home Groups. This service is missing in the Windows Server machine.
So, I suspect the missing service as the reason that the SecureChat sample won't work on the Windows Server machine, but I don't understand why Microsoft would lock out Peer Channel from working on the Server product. Could this be the reason?
Thanks!
Try enabling these services on the server:
Peer Name Resolution Server (Install through Server Management)
Peer Discovery Server (Install through Server Management)
Simple Service Discovery Protocol Service (SSDP Service)
Then simply ensure that the Firewall Rules are modified; by default they block IPv4 / IPv6 Teredo Tunneling driver. IPv6 needs to be supported as it is required by PNRP.
Also you should be able to configure your service in two ways; through Internet Information Systems (IIS) or as a Windows Service. Your best bet will be to use IIS, you can find an article here on how to configure it: Hosting and Consuming WCF Service
Those are the few tips I can think of to get it running. Hope that helps.
This MSDN page mentions this subtle detail of Windows implementation of PNRP:
Any two clients running the same version of PNRP can locate each other
using this protocol...

Delphi / WCF SOAP connectivity and Virtual Machine (VMWare) settings

I've got a working WCF service and a working Delphi client. On a normal PC, they work nicely. On a VM that's "Bridged" they work nicely if I log onto the domain (but not if I logon locally to the VM as administrator). If the VM is NATed, the connection attempt times out.
I would love to hear people's thoughts on what could be making such a difference to whether the client can successfully connect to the WCF service. Bear in mind I'm connecting with basicHttpBinding with no security.
The service is setup to use System Account (interact with desktop is NOT checked), and it starts automatically. The service URI doesn't change, the port is open, and can be telnet'd to in all scenarios.
Any ideas or pointers?
Within the VM, open Internet Explorer and verify that you can view the WSDL of the WCF service. If you can't, then your issue is connectivity and has nothing to do with your Delphi code.
Group Policies and Enterprise Security solutions that swap certificates or require certificates to be registered (we're using a UTM called CyberRoam) make a difference.
Also when Virtual Machines join a domain, their ComputerNames are added to a list maintained by the Domain Controller. When the same Virtual Machine is "moved" or "copied", its ComputerName should be changed to avoid DNS resolution issues.
I'm not claiming this as the definitive answer, however it does explain the issues I noticed in this instance.