A step by step instruction can be found here:
http://www.randomtechtips.com/change-logon-account-for-sql-server-service/
1 – Create a dedicate domain account to be used for the SQL Server Service – don’t get into the habit of using your own domain admin account to run services – systems will break when you leave and your reputation will be shot!
2 – Using your Admin tools, open Active Directory Users and Computers
3 – Right-click on an Organizational Unit that will contain your domain user account
4 – Click New, User, create a user account with a meaningful name, with a meaningful description
5 – On the SQL Server, click Start, SQL Server Configuration Manager
6 – Click SQL Server Services, in the right window pane, right-click SQL Server , click Properties
7 – Click the Log On tab, click “This account”, click browse
8- Select the Run Account created earlier
9 – Enter the password (twice to confirm) in the Log on tab, click OK. When prompted to Confirm the Account change, click Yes to restart the service. Click OK to close the properties page.
Ensure the SQL Server service is running with the new domain (service) accoun
Re-run the Prerequisite Check for SCCM 2012 and validate that you do not see the prerequisite for SQL Server service as a warning or failure.
Firstly, SCCM 2012 isn't actually flat, you can (and should) create folders to organize your different types of collections in the console.
Secondly, I realise that doesn't really answer your question because you're asking about how to deploy settings, applications, updates, etc to a group of collections at the same time, and folders don't help with this.
The way that we do this is by using "Include Collections" (and "Exclude Collections") membership rules. You create what would have been your parent collection, and then add "Include Collections" membership rules to that collection for what would have been your sub-collections. This ends up being much more flexible than the old system because you can easily Include different combinations of collections into your new "parent" collections.
For instance we have a number of collections for server patching based on the servers job, location, risk level and where it sits in our patch cycle, this will then be included in one collection to get its maintenance windows (usually based on something like its location/time zone or usage pattern) and included into a second collection to get its list of approved updates deployed (usually based on its job and risk level), eg:
Best Answer
I believe you can just change the port that is needed. SSB is a SQL side process and not a ConfigMgr port, you can just change it back if it does not work.
You cannot just change it though, I think you have to drop and recrete the broker endpoint, you can use this command to drop the endpoint.
You can then use this command to recreate it:
Always worth a test in a lab environment though first and a backup of your ConfigMgr site.