Profiles printing problems

hello

got a really strange problem with sims and printing from profiles.

After a reboot then login you can print one report fine, once it is has printed you then go to select the next report and nothing prints, you have to reboot your machine in order for it to work.

i am login as a domain admin on the work station and it is a windows 7 64bit machine. If i login locally on the pc printing from profiles is fine.

I have blocked all gpo's from my machine and account and still the same problem.

cleared the tmp files as well. I can see the xml file being generated in the temp folder on the machine once i try to print it.

any ideas

mark

I had similar problem, although I can print multiple profiles as long as I select them all at once. If I then select another for reprint, nothing happens. Rebooting machine allows me to print another. Case logged with Capita but answer very frustrating as I got the normal spiel about making sure tags were all correct, template verified etc. Even though I had printed 350 full profiles successfully but couldn't select lone ones for re-printing.

I'll try doiing a load in one hit see how that goes, then I'll have to reboot to try again.

It does create a error log in the temp folder as well, I did pass this over to captia but got told network problems. Yeah thanks for that

Seen similar things with different areas of SIMS for a while. For us usually to do with Data Reports and AM7 individual reports. Only ever the Word ones that effectively mailmerge data. I have a feeling that all the changes in Office 2010 aren't accounted for. That is assuming you're using Office 2010.

The other key factor has also been Windows 7!

One other thing to troubleshoot is to login as the administrator account if possible, sometimes, being domain admin isn't enough. Usually it's just your account with extra rights. Also, most likely your account has a roaming profile, and we've had no end of trouble with that.

Try with the Administrator account which i think would have a local only profile, and also try with a brand new roaming domain admin profile, i.e. one that is fresh and never used on an older OS. We had issues with not having properly redirected folders such as appdata and my documents, which then left legacies on the roaming profiles.

We fixed most problems and generation of data reports is fine, as is multiple generation of AM7 Individual Reports, but as with you if we try to bulk print it fails. The files all generate to the local appdata folder okay, it's the print process that is failing.

In Profiles, do you have the option to export all the reports to a folder, and then print after? It's the best workaround that most people are using at the moment.

Also, we found that having offline files on was an issue. The template that SIMS used could only be used once, and then it couldn't be used again until you logged out and back in again, at which point it was synchronised. Weird.

We had this exact issue last week, after many hours of playing we found there was something in the redirected app data mucking it up. Clearing that once fixed the issue.

Seems it creates a temp file there, that doesn't delete unless you clear it once, then it's happy. Don't ask how, or why but worked for us :P

Steve

Interesting Steve, have you got more details on the file...?

Quote:

---

Originally Posted by vikpaw

Interesting Steve, have you got more details on the file...?

---

Can double-check with NM on monday.

We had exact same thing, no-one can print more than one "set" of reports. Can print 1 or 100 first time, after that nothing.
Local admin works fine, domain admin has same issues etc.

We found creating a brand new account/profile, you don't get the issue on it. And as mentioned, after messing around a few hours it seems its something in AppData. But yeah will check on monday with NM for exact file/folder.

Steve

I'm fascinated by this whole problem. We've had similar for ages, and as per the various routes of troubleshooting we've tried as mentioned in previous posts here and elsewhere, i've found a few exceptions, as you have regarding local admin, domain admins failing etc. Not logged a case with Capita, as they will no doubt, as they have to others, just send us back with a trivial response. However i think they're right to do that in this instance, where if it works for one user, albeit in restricted circumstances, it can't be a fault in SIMS. It could be bad coding, that isn't flexible enough to work in a day-to-day environment, but we need to prove this.
I really hope this file you've located solves the problem for us and AM7 reports, as i've spent the best part of last week, creating registry hacks and vbscripts to workaround these problems.

I've seen similar at my last school. Printing direct from the SIMS server worked fine, but network accounts on other computers could print once and once only. Didn't matter how many were printed that first time. Annoying when you print one to check things first!

And we still have it and it is VERY annoying!

Does make me think about the appdata folder. That is redirected for network accounts. I'll remove redirection on my account and see if that works. Kind of glad it not just us. Thanks

If that doesn't work, go back to basics and try a non-roaming profile user, because that doesn't fail so far in my experience.
I've got as far as fixing the appdata redirection for a network user and this fixes the standard data reports, but bulk printing out of AM7 still fails, but it is using the appdata\local\temp folder. That isn't redirected anyway, only the roaming part is redirected, so i'm a bit flummoxed as to where to look next. The user has full control over that local folder and subfolders but still it errors.
Maybe @Steve21 can shed some more light on things by naming and shaming this file...

We now have a case open with captia. I did get told they have seen this with cc4. We don't run cc4 here but I'll post an update when I get any feed back from captia

Mark

I see lots of issue fixed on windows 7 with SIMS & FMS and the problem been down to the owner of the files. We now change the owner of files in the C Drive from "Trusted Installers" to "Administrators". Since doing this on new Windows 7 PC we have seen the number of support calls for windows 7 machine drop. This might be of help to you.

Quote:

---

Originally Posted by vikpaw

Maybe @Steve21 can shed some more light on things by naming and shaming this file...

---

Apologies, been hectic here. It's the template folder of Offices in AppData.

Seems case been raised a bit higher at Capita now too :P Woot!

Steve