1. All your AV services should not be associated with domain accounts unless you forced that to happen. By default when you run the permissions wizard it needs two domain accounts: one for messaging facing services (AvCsGateway, AvCsMgr, AvGaenSvr, AvMsgStoreMonitor, AvUMRSyncSvr) and one for directory facing accounts (AvDSAD, AvDSGlobalCatalog or similiar for 55 or Domino). The other services (AvDirChangeWriter, AvLic, AvMMProxySvr, AvRepDirSvrSvc, AvSQLChangeWriter, AvTTSSvr) all default to being "LocalSystem" unless you forced it to a directory account in the permissions wizard interface. There's no reason for these services to be associated with a domain account.
We had to introduce the 2nd account (i.e. seperate messaging and directory rights into two domain accounts) because of all the issues with explicit denies on the mailstores being introduced across various groups (i.e. domain admins among others) - it was nearly impossible to cram it all into one account and make it fly - we were getting _way_ too many calls about permissions issues as a result so we seperated the accounts with makes this a lot easier.
2. The AA is now the "Personal Communications Assistant" - the updated interface has a lot more to offer and is also where folks using VMI go. Here's the link in the admin guide talking about how to set it up and use it:
No, there's no limit on the number of admins you can have on the box. Check the class of service you're trying to use here (the Default Administrator COS) and look on the "licensed features" page and I'm betting you have an option checked for which you are out of licenses. Either that or you didn't apply your license file properly on 4.0(1) and your out of licenses subscribers - you can check this on the "Licnesing" page in the SA - there's two pages, one for counts of users (total users you can have) and one for licnesed features (how many seats of VMI, TTS etc... you can have). One of these is going to be maxed out I'm guessing which is why it's not letting you change COS assignments.
If the system is working there's no reason to change the rights assingments - there's nothing wrong with a few of those services that normally run under "LocalSystem" being assigned a domain account instead. I'd probably just leave it alone.
Not sure what you want in the way of a "fact sheet" here... The help file for the Permissions Wizard gives a very detailed list of all the rights it grants to each account - that's probably the best I can offer. If you don't have it handy, you can get it here:
The IIS question was answered on another thread - there isn't a folder/file that is going to show the PCA web root or the like, the new PCA is all done in Java with STRUTS and you get there via a redirection service added into IIS by installation - I suspect you disabled this redirection capability and this is why you can't get to the page.
What you are seeing is totally expected, but not always easy to find documentation on. The 4.0(1) release notes should cover both of these changes and more. For the issue about the accounts for the services, that's done by a wizard that's run during the 4.0(1) setup/upgrade...
IntroductionCUCM Routing RulesDial String implementation PolicyCUCM Routing LogicSIP URI Call Routing Analysis+++ Case Study: 1 ++++++ Case Study: 2 +++Conclusion
Over the last few months, I have had the privilege of working on SI...
Are you getting this error “Installer User Interface Mode Not Supported. The installer cannot run in this UI mode. To specify the interface mode, use the -i command-line option, followed by the UI mode identifier. The value UI mode identifiers...