nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

"Modified by" file property is showing weird IDs

gururaj

In the Teamsite Delevoper console, in the file properties,the "Modified by" property is showing weired IDs.We have a format "Domain/ID" but this is getting replaced by some unknown long IDs.

This has turned all of sudden.There has been no environment change.

Please let me know if anyone has experinced this earlier and solution.

Thanks

Find more posts tagged with

Comments

Migrateduser

Are the ID's that are showing up numeric? Are they consistent? For instance, are all of user A's ID's showing up as something like "55932012" instead of being random each time?

Also, and most importantly, what version of TS and what platform are you on?

Dave

Current Environments:
(1,2) TS 6.5 on W2K3
(3) Vignette V7 Portal on Solaris 9

gururaj

Thanks for reply Dave,

We are using TeamSite 5.5.2 on Windows NT Server.

These IDs look like " S-1-5-21-17961710-896403237--1224779798-u]@ " they have to be something like "<domain_name>/<9-digit number> "

The IDs are not same for all the files.
They have chaged for differnent for different users.

gururaj

They have chaged for differnent for different users.* has to be read as "IDs are different for different Users"

stefanmaier

Hi,
some months ago we had a similar problem in our TS5.5.2 windows environment (I assume that you are on a windows platform, too. Am I right?)
Suddenly the TS server stopped to resolve the windows SIDs into readable usernames.
Our TS server was the only server which had this problem in our windows environment
Solution was a to reboot our TS server...

Regards
Stefan

Migrateduser

Right, but any one user has a consistent string. Is that correct?

The string you gave looks like where this user's information is/was stored in the backing store. Can you verify that the backing store has not been corrupted and/or these users are set up properly on the Windows box? Is this kind of thing showing up for ALL users?

Dave

Current Environments:
(1,2) TS 6.5 on W2K3
(3) Vignette V7 Portal on Solaris 9

Jamik

We use run into that problem a lot when we were on 5.5.2. Basically that id is the windows uid for a given user. Even in the new versions you can see that problem show up on windows boxes if you delete a user from your system and they still have content that was modified by them. Basically when windows tries to look up that username it can't find it so it defaults to displaying the system id for that user. However, we also ran into this problem on 5.5.2 when the entities database got corrupted and usually required a restart of the server to fix. At least I think that's what the problem was it's been well over a year since we last had the problem since we upgraded to 6.1 last year and haven't had the problem since.

Migrateduser

Oh, and since I haven't seen Lissa or ghoti on this post yet, I'll give you the party tagline:

Since 5.5.2 is end of life, you should look into upgrading to 6.1 or 6.5 as soon as possible.

To add to that, I believe 6.1 is going to be end of life in a few months anyway, when 6.7 comes out.

Dave

Current Environments:
(1,2) TS 6.5 on W2K3
(3) Vignette V7 Portal on Solaris 9

gururaj

Thanks for your replies....

The Changed IDs are cosistent for each user.

Please let me know how I can verify that the backing store.

gururaj

Thanks Dave we are upgrading from 5.5.2 to 6.5 in near future on Windows 2000 Server.

nipper

If you traverse the Y drive, what are the permissions on the file ? Who owned, modified etc ?

Domain users or local users ?

Is there a submit.cfg ?

Adam Stoller

To verify the consistency of the backing store - use iwfsck with the '-d' flag only (RTFM for details)
If you think it may have been a temporary failure to resolve userids - you could try doing an:
iwstoreadm -d default
iwstoreadm -a default

and see if that fixes things.

If your accounts are all coming from a domain controller / active directory server / LDAP server - see if you can verify that *those* servers haven't been recently modified - if so, you may have to use the iwidmap CLT (RTFM for details) to restore sanity to your UI.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

gururaj

As per suggestion we ran "iwfsck -d -p -r -o output.log -e error.log" but there are no errors.

Total points walked: 51290962
Directories walked: 54536
Files walked: 1267328
Symlinks walked: 0
TeamXML files walked: 0
Zombies walked: 264567
Total points read from disk: 3408794
FINISHED 0 errors found

But still the weird IDs are coming.
the backing store has become slow.
From the Developer GUI we ,its very slow to access the branches and files.This has become even before running the iwfsck command.

Adam Stoller

I suggest (a) you look into the use of iwidmap, and (b) you contact Support -- not necessarilly in that order.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

carnix

Those weird ID strings are Windows SIDs (security identifier). For info on what that is, check out:
http://www.webopedia.com/TERM/S/SID.html

Anyway, this happened to me on 5.5.2 when out IT department decreed the TeamSite server be removed from the domain, even through all users were logging in with domain accounts. So, I created local user accounts for every (ugh) and when the server was taken off the domain (and, therefore, couldn't contact active directory), everywhere that once showed user names now showed SID strings. Very ugly, and very annoying.

The slowness you are experincing, if its the same reason as was for me, is TeamSite trying, in vain, to contact your domain controller. You can use a TCP monitor to check if that's the case, or get whoever monitors your firewall to check the logs and see whether traffic is being blocked there.

I haven't yet encountered this issue on 6.5, but if I took it off the domain (we now use VPN-only access for non-local network users to avoid the security problems IT was concerned with before), or blocked access between the TeamSite server and Active Directory, I'm sure the same problem would occur.

You should double check that nothing has changed on your TeamSite server with regards to user accounts. This includes the domain controller, if you use one, and all the interconnections in between (router, firewall, host file... whatever). Verify that the user accounts are stil there and haven't been deleted then recreated, because it just doesn't work that way. If you create a user account with the username Bob, then give him exclusive access to bob.txt, then delete the Bob account and create a new account called Bob, Bob wouldn't have access to bob.txt because, as far as Windows is concerned, the two accounts are NOT the same. (for good reason, it would be really bad from a security perspective if this wasn't the case)

-mike

Michael Langford, Webmaster - CARE USA
151 Ellis Street, Atlanta, GA, 30303
http://www.care.org/