After finishing the previous preparations, we can connect to a Lync client virtual machine for testing, because we have a router, so as long as the VLAN and virtual network are consistent with our router environment, we don’t need it To configure the IP address, etc., you only need to install the Lync client. After setting up, we first check whether the IP address has been automatically obtained.
Then we PING meet.contoso.com, pay attention to contoso.com, not the ADDS domain contoso.local.
Then we start the Lync client and enter the credentials of the created Lync user.
If it is correct, it will prompt us to connect to lfe.contoso.local instead of lfe.contoso.com. This is because our SIP domain is different from our ADDS domain.
After we log in, we can simply test various functions. Here we have not deployed functions such as enterprise voice, so it is slightly empty.
Then we shift and right-click the Lync icon in the lower right corner, and then view the configuration. We can see the internal and external configuration. Although our Lync has set the external URL to contoso.com, why do we still connect to contoso.local? Because we only have a front end, no edge, and the URL here is not the address we are connected to, but the internal and external functional URL address, such as the address book, etc., instead of actually carrying our URL. The actual carrying us should be one The server FQDN, not a URL.
As we scroll down, we can see that our connection status is TRUE internally, indicating that we are an intranet user, but in fact we are actually logged in externally.
So how does Lync judge whether we are connected internally or externally? In fact, it is very simple. It is through the edge server. If the edge server is carrying our load, then the internal state in the configuration will be False. Otherwise, the one directly connected to the front end must be internal. In addition, in this environment, because our ADDS domain is different from the SIP domain, we have to be able to resolve the lfe in our lcontoso.local externally, which means that the FQDN of the Lync front-end must be resolved. In the case of edge servers, this A record is required both internally and externally.
If we do not have this A record, then no matter whether we manually configure the login address or automatically configure the login address, we will never be able to log in. Because when Lync finds that we have not found the edge but the front end, Lync will determine that we are intranet users, and intranet users can parse all the records in the contoso.local domain, and naturally include the FQDN of the Lync front-end server , In our environment this is lfe.contoso.local.
So if we cannot resolve this address, then we can still automatically find the login server address and prompt us to enter the password, but no matter whether our password is right or wrong, we cannot log in successfully.
Let's try to log in on the web again. We will test in both cases. The first case is that it can be resolved to lfe.contoso.local externally. First, let's open a whiteboard, whether in the client or in the browser.
Then we share the desktop, there is no problem.
Next, we did not install the client on another computer, and cleared the A record of lfe.contoso.local, we opened the browser client again, we can still share the desktop and programs, but then the Lync browser client It will remind us that we cannot demonstrate whiteboards, voting, etc. due to network problems.
We can't share the whiteboard, and can't see the whiteboard shared by others, but we can still see the shared desktop and programs, and basic IM functions are possible.
In the case where the ADDS domain and the SIP domain are different, we must ensure that the external party can at least resolve the FQDN of the front-end server of the ADDS domain, otherwise some functions are restricted in the Lync environment without edges. Of course, there are many functions that can also be used in the browser client, including audio and video, IM, desktop, program sharing and other functions that can be used directly. But it is better that we can still unify the SIP domain and the ADDS domain, so that Lync can be used better without increasing the cost and complexity. Of course, what is said here is an environment without edges, if there is an edge, it is not necessary The SIP domain must be the same as the ADDS domain. That's all for today's content. Thank you for your support. If you have any questions, please feel free to point out. Due to my limited environment, the test may not be very comprehensive. If a friend can do a detailed and comprehensive test, it would be better.