Yes, you will need to create the jobs on any other replicas that you would want those specific jobs to run if they were the primary replica.
You will need to create your own logic for if/when each SQL Server Agent job will run. For instance, do you want to run a job only if the current instance is the primary replica of a particular Availability Group? You will need to put that into your job. It can't be blanketed automatically, because that would take away the flexibility of AlwaysOn AG. Whether you want them disabled on the secondary replica(s) is completely up to you, what those jobs do, and how/when/if you want them to run.
Remember, the secondary replica server isn't just a stand-by server waiting for failover. It could be a fully functional, accessible server. Because of this, having every job sitting by idle would be a huge disability.
So, yes, you will need to push our your jobs to other replicas and use some logic as to if the job should continue execution when it kicks off.
For instance, backup jobs can take advantage of the sys.fn_hadr_backup_is_preferred_replica function by determining whether the current replica is the preferred one for a particular database. This will derive how you have your Availability Group setup for backup preferences.
Elijah. There's two separate questions here:
1. Is DTC supported with AlwaysOn Availability Groups?
You're using SQL Server 2012, and according to Microsoft's Documentation, that answer is no. I totally understand that you want to try it anyway, but keep in mind that you're now putting something into production that Microsoft simply will not support, AND you're using two separate niche features together (AGs and DTC). If anything whatsoever goes wrong, you're going to be in a world of hurt. This just isn't something I'd ever even think about trying in production.
Keep in mind that if your managers find out that you deployed something Microsoft specifically says in big letters, "YOU CAN'T DO THIS," and you have any kind of outage where you have to call Microsoft for support, you're going to have some ugly explaining to do.
Technically, DTC is supported starting with SQL Server 2016 SP2 and later, but it just means that you can pick which database loses data on failover, and the application has no idea data was permanently lost. That's not what a normal database administrator would call DTC support.
2. How should DTC be configured in a multi-node, multi-subnet cluster?
Read Allan Hirt's post on configuring DTC with multiple instances of SQL Server in a cluster, and make sure to read all of the links in the post as well.
Best Answer
In SQL Server 2014 & 2012, adding the SSISDB as an Availability Database in an Availability Group is not supported. My understanding is that with some workarounds, adding the SSISDB to an AG is possible, but not supported. The workarounds sound error-prone, and I've not attempted it personally.
Rather than adding the SSISDB to the AG, I'd suggest evaluating the business needs (High Availability and/or Disaster Recovery), and see what other options are the best choice.
Depending on your HA/DR needs, consider maintaining two parallel SSISDB catalogs, one on each AG server. From an operational perspective, you will need to ensure that SSIS packages are deployed to both servers, and that they are kept identical (packages, permissions, etc). This would give you the ability to use the locally-installed SSIS service on either machine to run packages for HA/DR. You would also need to make sure that you do not have SSIS packages running on both servers.
In SQL Server 2016, adding the SSISDB to an Availability Group is supported & documented. If upgrading is an option, you may consider that as well.
Within your SSIS package connections, you can use the AG listener to connect to the active node of the AG for data access. SSIS does not need to run on the same server that is hosting your data.