Dante Certification Level 3 – Chapter 03: Dante Domain Manager

Level 3 – Chapter 03 – Dante Domain Manager

In this chapter, we’re going to take a brief look at Dante Domain Manager, why it exists, and how it transforms the way you manage Dante Networks. We’ll explore the architecture and design of DDM, how you access Dante controller and how you manage users clocking, system monitoring and integration with external services such as LDAP, email and SNMP. Whether you’re new to DDM or you’re looking to deepen your expertise, this chapter is designed to give you an introductory understanding of its capabilities. Please take into consideration that this chapter is only a brief summary of the comprehensive DDM Administrator certification course that we have in our training platform.

If you really want to go deeper into DDM, we recommend you go there and take the complete certification. Let’s start with the basics. What exactly is Dante Domain Manager? Well, Dante Domain Manager is a server based software platform that’s designed to manage Dante networks in complex or large scale environments.

Traditionally, Dante networks work beautifully in plug and play scenarios, especially when all the devices are the same subnet. As AV systems grow in size and sophistication, especially across multiple floors, rooms, buildings, or even cities, the need for centralized management becomes more critical. DDM addresses these needs by acting as a centralized management layer that sits on top of your Dante network. Think of it like the air traffic control system.

For Dante, it doesn’t handle the actual audio and video data. In fact, DDM is not in the audio or video signal path at all. Instead, it coordinates communication manages devices, applies user permissions and keeps everything synchronized and organized. If the DDM server goes offline, media signals keep flowing uninterrupted, but you won’t be able to make any changes until the server is back online.

For this reason, critical systems often deploy DDM with high availability configurations, which will see next DDM is delivered as an ISO file, a software application that you install on a virtual machine or server, it runs on Linux and is designed to be treated as an enterprise grade server platform. The most common deployment is within a type one hypervisor like Prox, Mox or VMware ESXI. These environments provide the stability and performance needed for permanent AV system infrastructure. Type two hypervisors such as Oracle Virtual Box may work for testing or demonstration, but they are not suitable for production systems due to operating system instability or update behavior.

As such, Audinate does not recommend the use of Type two hypervisors. If you want to see the installation process or any requirements for DDM, you can find all the information on our website, get dante.com or take our full DDM admin course. As we said before, DDM support server redundancy, also called high availability or ha. This involves running a cluster of 3D DM servers at the same time.

In this configuration, 1D DM server acts as the active node running the application. Normally, another will act as an auxiliary node, which automatically will take over. If the active node fails, the third DDM will run as an arbiter. This acts as a tiebreaker.

In the event of a network split or a server failure in an HA environment, Dante devices connect to a virtual IP address that represents the entire HA cluster. In the event of a failover, audio and video signals continue to flow uninterrupted and control returns as soon as the auxiliary node takes over. You can promote nodes manually or allow DDM to switch automatically based on failure detection. DDM is designed with flexibility and stability in mind, but it’s important to highlight that when you install DDM for the first time, you’ll need an active internet connection for license registration.

Once licensed, the server can operate without an internet connection, making it suitable for restricted networks. However, for licensing updates, NTP clock sync and support access online connectivity is recommended. Let me show you how you can access DDM Once it is installed. You need to go to the IP address or the fully qualified domain name that you assigned for us.

That is 10. Do 1 0 2 20 10 or D dm.eu two do Dante L. Once you have entered it, you’ll be prompted to enter a username and a password. Each person on the network can have their own login credentials with different roles and permissions assigned to them.

We’ll talk more about that later in this chapter are, once you log in, the first thing you’ll see is the dashboard. This gives you an overview of how your DDM system is doing. On the left hand side, you’ll find all the tabs and tools you’ll use to manage your devices and domains. When deploying DDM, one of the first decisions you’ll need to make is how devices will get their IP addresses.

We already know that Dante Devices Support three. Addressing Methods DHCP or Dynamic Host Configuration Protocol is ideal for medium to large installations. A-D-H-C-P server assigns IP addresses automatically and DDM can easily find and communicate with these devices. Link Local addressing or a Pippa is commonly used in smaller setups where no DHCP server is present with this option.

Devices self assign an IP in the 1 6 9. Do 2 5 4 dot anything, do anything Range. Link local works well for standalone setups but is not recommended for managed networks. It uses one big slash 16 subnet and cannot be routed to other subnets.

Static IP addressing is where we manually enter ips for each device. This provides control but can be labor intensive and prone to human error, especially with a large number of devices. A good practice for larger networks is to use DHCP reservations. This combines the ease of dynamic assignment with the consistency of static ips.

Devices always receive the same IP address based on their MAC address, ensuring stability while simplifying management once your addressing scheme is in place. The next step is discovery. In simple Dante networks, automatic discovery happens via MDNS devices. Announce their presence and look for others on the same subnet.

This kind of setup only works if everything is on a single subnet. You can think of it like your phone finding other devices on the same wifi network or when you stream music to a wireless speaker. It’s all happening within that one local network. Here’s the downside.

If we rely on this method, we won’t be able to use Dante Domain manager’s High availability feature. High availability requires a DNS server for device discovery and MDNS. The discovery method used in a single subnet environment doesn’t provide that. When your network spans multiple subnets multicast discovery will not be routed by default.

This is where DNS service discovery or D-N-S-S-D comes in. D-N-S-S-D allows devices to locate the DDM server using standard DNS records. It supports automated discovery across multiple subnets, making it the preferred method for scalable networks. For this option, A-D-H-C-P server is strongly recommended to assign IP addresses and DNS server addresses to devices along with D-N-S-S-R-V records in the DNS server.

For DDM discovery, if automatic discovery isn’t feasible, manual enrollment options are also available. You can input IP addresses directly into the DDM web interface or use the connect devices to DDM option in Dante. Controller devices will then report into DDM allowing you to assign them to specific domains. Let me show you, We’ll start by enrolling a device that shows up in Dante controller.

In this case, the device is called Office DVS, and we want to move it into the office domain in Dante Domain manager. To do that, we go to the DDM web interface, click on devices, then select enroll devices. From there, we choose the domain we want. Again, that’s the office domain and enter the IP address of the office DVS device in the enroll by IP address option.

Once we hit enroll, that device disappears from the unmanaged domain and Dante controller and gets enrolled into DDM under the office domain. If we now go to the office domain, we’ll see the office DVS listed there. This demonstrates a successful enrollment into a DDM domain. Okay, here’s a quick reminder.

Dante controller must be in the same subnet as the Dante devices. We want to push to the DDM server. That’s important. Another way to do this is by using Dante controller directly.

Since we’re here, I’ll take a moment to show you how to connect to Dante Domain manager. Once we’re in Dante controller, look for the globe icon up in the toolbar and click on it. That brings up the connection screen here. You can enter either the server name or the IP address of your Dante domain manager.

In our case, we’ll just use the IP address. Go ahead and type in your username and password to log in. Once you’re logged in, you’ll see a dropdown menu in the top right corner of the window. That’s where you’ll find your list of domains.

For me, it shows that I’m logged in as the admin, and right next to that is a selector where I can choose which domain I want to work in. By default, Dante controller displays the unmanaged domain. That’s where you’ll see devices that haven’t been enrolled into Dante domain manager yet. On my network, we can see some that need to be put in a secure domain, and if I switch over to the domain called meeting rooms, we can see some other devices.

If I choose Campus theater, I’ll see the devices that are active there as well. At that point, we just use Dante controller like we normally would. Okay, now let’s go back to what we were talking about earlier. If for some reason you’re not seeing some or even all of your devices in DDM, there’s a way to fix that.

First, you need to be in the unmanaged domain. Then just go to the device menu and choose the option that says, connect devices to DDM slash Dante Director. A list will pop up showing the devices that are available. All you need to do is highlight the ones that aren’t showing up in DDM or the ones you want to connect.

Click okay and that’s it. They’ll be added. Dante controller pushes the DDM server configuration to those devices. Then over in the DDM web interface, you’ll see those devices appear in the unmanaged section automatically.

From here, we just need to assign them to the correct domain, simply drag and drop the devices into the office domain. They’ll instantly disappear from the unmanaged section, and if we check the office domain in Dante controller, we’ll see they’ve been enrolled correctly. Now that we’ve talked about Dante controller, we should remind you that even with DDM in the mix, Dante controller remains your go-to tool for configuring individual devices, managing subscriptions, and reviewing real time status. The key difference is authentication.

Users must now log into DDM through Dante controller to gain access to any managed device. Once logged in, users will only see the domains and devices they’ve been granted access to adding a crucial layer of security and organization. Now, let’s dive deeper into domains. A domain is a logical grouping of Dante devices that are managed together.

Under DDM, think of it like a folder system for your network. Each domain can represent a physical space like a meeting room or auditorium or a functional zone like a recording studio or broadcast booth, or any logical structure that suits your environment. This organization drastically improves clarity and usability. In Dante controller, especially for large networks, each device can only be part of one domain at a time.

Devices enrolled in a domain are isolated from devices in other domains. By default, this isolation includes both control and clocking devices in different domains. Can’t see each other or share audio unless you specifically allow it. This is a major security benefit, especially in sensitive environments.

As a Dante system grows. Using DDM and creating Domains helps simplify Hard to read Dante controller views from something that looks like this to something that looks like this. Let me show you how to create and delete a domain. Alright, now that we’re in the DDM dashboard, let’s walk through how to create and manage domains.

We start by heading over to the domains page and from there we just click the add domain button. Let’s create the first one and call it classroom. Then I’ll go ahead and create two more, one called auditorium and one more named meeting room. If I create a domain that I don’t actually need, I can simply click on the one I want to remove and then hit delete.

Now that we’ve got our domain set up, it’s time to move our devices into them. To do that, we go to the devices page and here we see a section called unmanaged. This is where devices show up when they haven’t been assigned to a domain yet. There are a few different ways to enroll devices.

One method is to go back to the domains page, select the domain you want to work with. For instance, meeting room and choose the enroll devices option. That takes you to the enrolled devices page. Under the devices section, just click add devices and you’ll see a list of all the devices available For enrollment, I’m going to select just some of them.

Then click enroll, and that’s it. Another way to do this is directly from the devices page. If you’ve already named your devices to match their intended location, you can use the search bar to filter them. For example, typing classroom will show only those devices.

From there, just select the ones you want to move. Scroll down to the enroll option and click it. That takes you to the same enrollment screen as before you select the domain and enroll them. My personal favorite method is the most intuitive drag and drop.

Just go to the device list, scroll down past the unmanaged section and you’ll see all the domains we just created. Now just select the devices you want to move and drag them right into the domain and here’s a quick tip. Use shift or control to select multiple devices at once. Something that’s very important to highlight is that once devices are enrolled into a domain, they cannot share audio back to the unmanaged domain.

Okay, what about removing devices from a domain? That’s just as simple. Go to the devices section in the main menu, expand the domain where the device is enrolled, click on the device name and then select unenroll from the domain enrollment area. Another option is to go to the devices page, select the devices you want to remove from the domain and drag them into the unmanaged section.

You can also go to the domain details page and unenroll every device in that domain all at once. Here’s something else that’s really important. What if a device was removed from the network before being properly unenrolled? In that case, it won’t work on a new network because the device still thinks it belongs to a domain.

That means we’ll need to clear its domain credentials before using it somewhere else. This is what we call the lonely reset. Let’s take a look at how to do that. The first thing we need to do is isolate the device from the rest of the Dante network.

That could mean connecting it directly to your computer or plugging it into a switch that only has the computer and the device connected. Once the device is isolated, wait a minute or two and it will appear in Dante controller. When it shows up, double click its name to open the device view window. Then go to the device menu and choose clear domain credentials.

A new window will pop up and there you’ll click the clear config button. It’s also a good idea to reboot the device before using it on a new Dante system. That’s it. Once the credentials are cleared, the device is free to join any network or domain you choose.

Previously, we mentioned that each device can only be part of one domain at a time, and once devices join into a domain, they cannot see each other or share audio unless you allow it. The question then becomes, how can I allow it? Let’s introduce the concept of shared audio groups. This feature allows specific audio channels to be transmitted across domains.

Rather than moving devices around, you create virtual transmitters that appear in multiple domains. These virtual devices can be subscribed to just like regular Dante devices and you can even rename them per domain. For clarity, shared audio groups are perfect for scenarios where A DSP is serving multiple rooms or sending performance audio from a theater to recording studios elsewhere on campus. Let me show you how to do it.

Before we create a shared audio group, the very first step is planning. We need to ask ourselves a couple of questions, which domains are going to be involved and what audio channels do we want to share between them? Let’s give an example. Imagine we’ve got a live performance happening in the campus theater domain and we want to send that performance to the campus classroom domain, so that means we’ll need to share audio between those two domains.

Right? To get started, we go into the campus theater domain and once there there’s a section called shared audio groups in that area. We need to give the new shared audio group a name. I’ll call this one performance and hit enter to save it.

Next, we click the edit button and this allows us to manage which domains are part of the shared audio group. In our case, I want to add campus classroom to the group. Once the group is set up, the next step is choosing the device we want to share audio from. To do that, we go to the list of domain devices and find the new one we want, which in this case will be the mixer.

After that, we’ll scroll down until seeing a section called TX channel sharing. This will only appear if the device is part of a domain that’s in a shared audio group. Now you’ll see three different options to share. In our case, we’ll click the option called selected domains and channels because this is actually what we want to share specific channels to specific domains.

If you want to rename the device, you can do it here so that it appears differently in the other domains. Let’s rename it mixer dash performance to keep it simple. Then under shared channels, I’ll select channels one and two because those are the ones we want to make available. I’ll also rename those channels to stereo left and stereo right, so it’s clear what they’re for.

Once that’s done, we click okay and make sure to save the changes. Let’s take a look at how this shows up in Dante controller. First in the campus theater domain, we’ll see our mixer just like we’d expect, but now if we switch to the campus classroom domain, something cool happens. That mixer now appears in green and it shows up with the new name we gave it.

When we expand it, we’ll see the two shared channels labeled stereo left and stereo right. At this point, we can subscribe to those channels with any device in the classroom domain. There’s just one important thing to keep in mind when working with shared audio groups. If both domains are in the same subnet, then all the PTPv1 clocking is still multicast.

That means those messages can be seen by all devices on the network because everything is running at layer two, so there are no routers involved, but what happens if the domains are in different subnets? In other words, they’re separated by a router and operating across layer three. That’s where things are a bit different. This brings us back to something we talked about in the previous chapter, and that is PTPv2, unicast clocking.

When you are crossing subnets, unicast becomes essential to keep clocking working correctly between devices in different domains. Okay, we learned that every Dante domain is its own independent clock domain devices within the domain synchronized to a designated clock. Leader DDM makes this process easier by automatically configuring clocks based on network topology and device capabilities. However, in multi subnet domains, DDM uses unicast PTPv2 to send clock data across subnets, ensuring all devices remain synchronized.

In this case, boundary clocks will act as translators receiving uncast clocking from the grand leader and sending multicast clocking within their subnet. To accomplish this, DDM provides tools to manually configure or override clock settings when needed, allowing granular control in advanced systems. Let’s take a look at an example. In this diagram, we see two different subnets, all with Dante devices connected across these two switches.

What will happen to the clock? Who will be unicast or multicast leaders in PTPv1 and PTPv2 or followers or passives? Let’s see it with real devices. Alright, let’s take a look at the setup.

In the first switch, we’ve got a Yamaha DM3 mixer, a focus right RedNet interface and a computer running Dante virtual sound card. All of these devices reside in the 1 9 2 1 6 8 1 1 1 0 subnet. On the second switch, which will be the 1 9 2 1 6 8 1 2 0 subnet, we’ve connected assure ULXD wireless microphone receiver and a Dante AVIO adapter. For this demo, we’ll enroll the mixer, the interface, and the computer into a Dante domain manager domain called Classroom A.

The microphone and the AVIO adapter will go into another domain, which we’ll call Classroom B. Each domain has its own subnet, and if we open up Dante controller, you’ll see that the devices in each domain are completely separate from each other. At this point, there’s no way to share audio between them unless we create a shared audio group, so let’s take a closer look at each domain. In classroom A, the system automatically selected the mixer as the clock leader.

That device is now sending out PTPv1 multicast messages, and the other two devices, the interface and the computer are following it over. In classroom B, the microphone has been chosen as the clock leader and is also sending PTPv1 multicast while the AVIO adapter is acting as a follower. So far, everything is operating at layer two using multicast for clocking, so no unicast is involved yet. What we really want to do is share audio between classroom A and classroom B.

To do that, we’ll go ahead and create a shared audio group in one of the domains. Let’s name it classroom’s sharing. Remember, for this to work, both domains need to be members of the shared audio group. Once we set that up, you’ll notice something new in the clocking section.

It now shows the clock type as multi subnet, and there’s a warning that says multiple primary leaders have been detected. That’s expected because each subnet has its own leader right now. So how do we fix this? The easiest way is to just click the auto configure button and let Dante domain manager handle everything for you, but since this is an advanced class, we’re going to do it manually so you can really understand what’s happening behind the scenes.

Let’s go to the advanced settings and take a look at the domain clocking section. Here we can clearly see that two devices have been elected as primary leader clocks, one in the 1 1 1 subnet and one in the 1 1 2 subnet. This occurs when PTPv2 messages are sent using unicast across a layer three network where devices in different subnets aren’t able to participate in the same multicast election. To solve this, we need to enable unicast clocking on both of these devices.

Once we do that, the system will run a new clock election to choose one device as the domain clock leader and the other as a backup. It’s always a good idea to have a backup device ready just in case the clock leader fails or gets disconnected. In our setup, we’ll make the interface and the AV O adapter, the unicast capable backups. If we go back to Dante controller and look at the classroom a domain under the clock status tab, we’ll see that the mixer is listed as the primary leader clock.

That shows up both at the top of the screen and in the domain status column. The interface shows as standby and it’s still following PTPv1 multicast. Why does it show as standby? Remember, a device cannot be a follower on multiple PTP ports at the same time, so in this case, it’s ready to take over if needed, but it’s not actively following unicast yet.

Let’s check classroom B. Here is where things get interesting. The primary leader clock appears as unknown, but if we hover over it, we’ll see its MAC address. If we compare it with the mixer in classroom A, we’ll find out it’s the same device, so even though it’s in another subnet, it’s acting as the clock leader for both domains.

Back in classroom B, the microphone now shows up as a follower in the domain status column. That means it’s receiving clocking via PTPv2 unicast and then acting as a leader for local PTPv1 multicast inside its own subnet. In this case, the microphone has become a boundary clock, bridging the unicast domain clock and distributing it locally using multicast. The AVIO adapter is also in standby mode for unicast and following PTPv1 multicast.

Just like the interface in classroom A, there are a few key things to remember when using unicast clocking. First, it only works through the primary network port of each device, not the secondary. When you want to confirm whether a device is using unicast clocking, just go to the clock status tab in Dante controller. The domain status column will clearly show you which devices are participating in PTPv2 unicast across domains.

Okay, let’s move on to user and role management. DDM offers a robust system for controlling who can do what and where You can create local users or integrate with LDAP. For centralized authentication, Every user must be assigned a role and those roles define their capabilities within DDM and Dante controller. The default roles are site control with full access to all domains and system settings.

This is ideal for administrators. Another is called domain control. These users can manage devices and clocking within assigned domains, and another role called media control, which is limited to making subscriptions and minor changes. Finally, the read-only role allows view access Only custom roles can be created to fit your specific needs.

You can assign different roles per domain or even set a user’s role to none for domains they shouldn’t see at all. This ensures only the right people can access the right devices at the right time. When LDAP integration is enabled, DDM can import users from your organization’s directory service. This streamlines management and eliminates the need for duplicate user databases.

You can define LDAP groups and apply DDM roles to each group. Users in multiple groups inherit combined privileges making this system flexible and scalable. Let’s start by creating a new user. We’ll head over to the user’s tab and click on add user.

First, we need to enter a username and password. In this example, I’ll use John Doe as the username and assign a password. It’s always a good idea to include an email address here too, just in case the user ever forgets their password and needs to reset it. We also recommend setting a default role when creating the user.

In this case, the default role is initially set to domain control, but let’s switch it to read only. Instead. Following good security practices is important, and giving only the access someone truly needs is a big part of that. Once the default role is assigned, we can go a step further and define different roles for specific domains.

For our user, John Doe, we’ll click add domain role. We’ll keep the read-only role for the meeting room’s domain, but for campus Theater we’ll give John the media control role, which allows more control over devices. We don’t want John accessing any other domains, so for those we’ll simply set the role to none. After that, all we have to do is click add, and just like that, we’ve created our first user.

Now, let’s jump over to Dante controller and log in with John Doe’s credentials By default, we’ll start out in the unmanaged domain. If we open up the domain dropdown menu, we’ll only see the two domains that were assigned to him, meeting rooms and campus theater. In the meeting rooms domain, John has read-only access so he can view devices but can’t make any changes. In the campus theater domain.

He has media control access, which means he can edit device settings and make subscriptions as needed. System monitoring is another core component of DDM. For example, the dashboard provides a real time overview of your Dante environment. Alerts are color coded and categorized by connectivity, clocking, subscriptions, latency, and general system health.

You can filter alerts by domain severity or type and even customized your dashboard layout. Each domain also has its own health card showing the device count and current issues. The audit log tracks every action in the system, including device enrollment, clock changes, user logins, configuration edits, and more. This is crucial for troubleshooting and compliance.

Essentially, nothing happens in a DDM managed network without being recorded. Finally, DDM supports integration with both APIs and external services. Since APIs will be covered in a later chapter of level three, we’ll focus on these supported external services. Email alerts, LDAP integration and SNMP email alerts are a service that helps you connect with your organization’s.

Email server alerts from the DDM dashboard can be sent via email to relevant personnel enabling proactive responses to system issues. LDAP integration, as already mentioned, allows user authentication and role assignment to be managed through your corporate directory. SNMP support allows DDM to act as an SNMP agent interfacing With enterprise monitoring platforms, IT teams can receive alerts and monitor Dante alongside their other systems. As you’ve seen throughout this chapter, Dante domain manager plays a critical role in managing and securing Dante networks, especially in complex or multi subnet environments.

From user roles and device visibility to clocking across domains, DDM gives you the control and flexibility needed to scale and support professional AV systems with confidence. Believe it or not, what we’ve covered here is only the basics. If you want to dive deeper and truly master DDM, we invite you to check out our full DDM Administrator Certification course available on our training platform. It’s packed with hands-on demonstrations, advanced topics, and real world scenarios to help you get the most out of Dante Domain manager.

We hope to see you there and of course, in the next chapter of level three.