We are installing a new Unity server (VM ONLY) into a voicemail server only domain. Another partner installed the other 4 existing servers and we have noticed that the installation/directory service/message store service accounts are not implemented per Cisco recommendations.
It appears that on all servers there is an account exchservice that is used for AvSDAD and AvSDGlobalCatalog, which is a Full Exchange Administrator. All other services run under the local system account.
this does not seem to be a conflict of the directory service and mess. store services accounts, correct?
My final question is: can we successful "right the ship" and use the UnityInstall (UnitySvc), UnityDirSvc and UnityMsgStoreSvc accounts, and not cause any problem on the other installations? Or should I continue with their convention?
All servers are Exchange 2000 on W2K. I ultimately want to implement Digital Networking.
Starting with 4.0(1) that old convention (local system) is not supported. However, even in 4.0(3), the service configuration wizard still allows you to choose local system (and defaults to it if you are upgrading from 3.X) for the account the message facing and directory facing services run under even thought it isn't a supported configuration. Clearly we shouldn't have a GUI that allows you to configure something unsupported so that will be changed in 4.0(4).
A big reason that we have changed our security model from using local system and putting the server in the Exchange Domain Servers group it is avoid the seemingly constant, often undocumented changes that Microsoft has been making as part of their Trustworthy Computing campaign. Here is a good example:
Exchange 2003 ForestPrep sets a 'Deny Receive-As' Access Control Entry (ACE)
for all 'Exchange Domain Servers' groups on all Servers containers within a
Forest. Each Administrative Group has a single 'Servers' container, which is
a child object that the Exchange servers within the Administrative Group are
placed in. The 'Deny Receive-As' ACE that Exchange 2003 ForestPrep adds are
propagated down to the mailbox stores by default causing members of this group
to be denied logon access to them. Microsoft documents none of this as far as I can tell.
So back to your situation -- if it were me I would go through and set those servers to use the supported methodology but you don't have to for this install to work correctly. This Unity server will not be effect by the permissions configuration on the others but they really should be updated. Updating them would entail re-running the 4.0(3) Permissions Wizard and then switching the services over.
Thank you for your thorough, late-night reply. I'm not sure why they were installed this way. I neglected to give you the versions - all 4 are 3.1 (5) so they were either upgraded (which I have not been informed of) or installed using old procedures from 3.0 days. My new server will be 4.0(3) SR1, so I will install according to procedure based upon your recommendation and address the others at a later time.
Ok...we have our lab up and running. I have the following scenario:
An Exchange 5.5 UM user was migrated to Exchange 2003. This newly migrated account was available for import in the Unity Server (4.0) parthered with the Exchange 2003 server, and upon inspection in adsiedit it did not have Custom Attribute 12, 13, 15 and the Voice ID attribute, instead there were "extension" attributes, which seemed to match.
If this is the case, when we tried to import the user, it was in fact available to Unity. Is this because Unity is partnered with the Exchange 2003 server and it no longer looks at those "extension" attributes, but instead the Ciscoxxxxx Attributes?
We later then moved it back to Exchange 5.5 and it was still available for import even though in Exchange 5.5 system manager, custom attributes 12,15 and Voice are still visible.
I am simply surprised by this behavior as I did not expect it to be importable with those attributes in tact. I am just trying to verify what seems to be the case in the lab.
The short answer is that you don't.... That isn't entirely true while at
the same time it kind of is, but for the most part you don't configure
the softkeys. You enable or disable them via TCL. Here is the long
answer. Be sure to read the whole thing or e...
Topology: IP Phone > Switches > Microsoft NPS setup to forward 802.1x
proxy to > ISE 2.1 patch 3 Authentication: EAP-TLS using Cisco MIC SANs
Phone Models 802.1X support? 802.1x flavor Addtl Comment EAP-MD5 EAP-TLS
Cisco 3905 Y Y N Cisco 6911 Y Y N Cisco ...
This document describe how DST changes and how time changes are
implemented in DST. Daylight Saving Time (DST) is the practice of
setting the clocks forward 1 hour from standard time during the summer
months, and back again in the fall, in order to make b...