We are using unity 3.1.4 and trying to change a Subscriber COS to administrator. As the user gets cannot access unity admin web page due to incorrect COS.
It lets us select the Admin COS and save it, as soon as we move from the subscriber to another menu or subscriber and come back the COS has not changed.
We have rebooted the Unity Box and also changed the default subscriber COS to enable the user in question to admin the Unity box, this worked ok, so I think the COS is ok, but the assignment in the subscriber profile page is where the problem lays. It basically does not save.
some weeks ago we made a user other than the Administrator a unity admin COS and that has stuck/saved ok. However if we try to change their COS it does the same.
odd... that's a new one. Does this do this for any subscriber and any COS you select? When you attempt to save this change and then notice that it didn't "stick" do you see any errors or warnings in the application event log? If you create a new COS and try to change a user to that, does it work (I'm wondering if may the admin COS is in a bad state for some reason)?
ok, I;ve tried what you suggested and checked back to the times we tried this morning and no errors at or near times in the log, just tried it again and same problem, this morning we setup the default subscriber as an admin COS and the user could then admin the Unity web page. I also setup another admin based on the orginal and this did the same, I can select it, save it, but it does not stick, I have also rebooted the box.
Thanks for any help you can give.
The next thing I'd check is to run the latest dbWalker version and see if any errors are reported (don't select to automatically fix anything, just run it through and see what pops up). That might give us a clue as to where to go next. You can get the lastest version here:
Thanks for that I've ran the Dbwalker and it reports only 1 error on the example subscriber - in the subscribers section it says (error) Primary Call Handler is not valid. I have checked all the accounts we have been looking at and these seem ok according to the report.
I don't think the problem lays with the COS as I can create COS without any problem and assign them, it lets me save the changes on the user ok, but as soon as I come out of the subscriber section or go to another subscriber and come back it reverts back to what its original setting was.
One thing I have noticed is that if I change any other attribute on the profile page of a subscriber I find that it also behaves the same i.e. last name change, however I changed the weekdays to all hours all days on the schedule on the profile page and saved it and this saved ok as well as other attributes on the messages page for example.
It seem to be just the Subscriber information on the profile page up to Active Schedule is this kept /grouped in one SQL table?
Cheers for any help you can provide.
I've never seen anything like that... no, all those attributes are stored in the Subscriber table (first name, last name, display name, COS, schedule, language info etc...) - it wouldn't be something like one table in SQL being "locked" or something like that.
I'll bounce this off the DB and SA folks and see what they have to say - with no errors being thrown anywhere I'm not even sure what to look at next.
Apparently this is a known bug: CSCdy13869.
The work around is to chang the subscriber's COS assignment on the COS pages in the SA not on the subscriber page for now... head to the "subscribers" page on the COS you want to assign the user(s) to and use the "reassign or "assign" options to move users around between COS definitions.
This has been fixed in 4.0, not sure when the next 3.1(x) release is planned.
ok, thats great, well not so great, but thanks for the help. One more thing, I have created a new account in Unity to get around the above problem this works ok, no problems assigning subscriber COS. SO..... I deleted an exiting account, and went to reimport the account.......
When I browsed the domain I could not see the account, the account is not listed as a user in the DOHPROPTEST tool, I suspect that there are still attributes in the exchange mail box, I read that we need to start exchange admin in raw mode and remove some attributes, is there any other way to do this, as the customer is nervious about running the admin tool in raw mode?
Thanks again for any help.
No... with Exchange 5.5 you have to do it in raw mode...
It's likely just a replication issue, however. If you wait a while I'm betting the attributes will cycle around and you'll be able to import them again.
The customer is running exchange 2k, I will be back on site tomorrow morning UK time, so I will check to see if replication in the AD/exchange has occured, however Its one site and in one AD tree so we'll see how it turns out.
From the previous message, is there any otherways to get around the above problem in Exchange 2k if the replication does not occur.
Thanks for all your help