OxMB

I know it's been a while since I last updated this. I wanted to let you all know the cause of, and solution to the problem. We use Smart interactive whiteboards here. With it comes Smart Notebook and Smart drivers. I can't remember exactly which part of their software suite it is (perhaps Smart Ink), but it installs Add-Ins for the MS Office Suite. Within MS Excel, if you go to File>Options>Add-Ins and within the COM section disable the Smart add-in you'll see there, the problem then disappears! NOTE for new people to this post, the problem that disappears is the EXACT one I have described, please do not confuse this with some other Excel problems. There are various Smart related Add-Ins (I think), but we could find no adverse effects from disabling the particular add-in I described. It is rather surprising that Smart Tech's add-ins interfere with the type of MS Office functionality I have been discussing in this thread. I believe my boss has checked that our Smart software version is not that old. Not too pleased with Smart's software development testing in this respect.

Just to let everyone know, we have now resolved this issue. Microsoft had a long queue, and they said they would get back to me. They did this by email using the wrong account (which was mainly my fault, a misunderstanding), although I was definitely expecting them to get back by phone. They eventually did this after a day and half. Microsoft first line (once I was actually talking to them) were better for me than they were for my boss. They pointed to likely user profile issues (local laptop users profiles), and they were right. I must admit I don't have the same instinct to go for user profile issues on non-domain devices as a I do within the domain scenario. Users in question had folders on c:\users which weren't named correctly, and may have had bad permissions. I recreated the affected users, copying work across. After that OWA 365 allowed a perfectly fine Internet Explorer based login. Is there something I should do to flag this as resolved?

mac_shinobi, that might be an interesting experiment. But this happens with any spreadsheet. We are not going to make all spreadsheets shared workbooks. Shared workbooks are for when you wish to collaborate in creating the spreadsheet. I am talking about the scenario where only one person should edit it, but loads of people need to be able to look at it from time to time. Now that I have found a computer where the problem does not occur, my focus will be on comparing it to other computers. I may even add software, change permissions, change policy, change location of this good machine toward the bad machines and see what breaks it.

I've just found a machine where it doesn't happen. Now to find out what's special about it.

ZeroHour, thanks for your input. It doesn't matter whether you are an admin with every tick in the Allow column and no ticks in the Deny column. It still happens.

ZeroHour, the main example I raised was where someone else already had the file open and the grey box giving the read-only option didn't appear. It would not be possible to test this using a memory stick. You'd have to share the memory stick so that two people could attempt to open the file. But then it would be a share! I could test re the other grey boxes you can get when an Excel file opens, like 'cannot update links'. I need to investigate the circumstances in which they cause a problem too. I suspect it may also be when someone else has the file open.

Thanks for your help mac_shinobi. Its getting late now, and I shall look through some of your suggestions tomorrow. However, looking at your point no.1 it seems you are talking about shared workbooks. I'm afraid I'm not. I'm talking about situations where a file is locked for editing, then a second user can't even click to view Read-Only because that box doesn't appear - Excel has already hung before it even gets to display the 'this file is locked' message.

Chris - pinned my hopes on the service pack. But just tested for the issue on two machines with Office 2013 SP1 installed recently. The bug presented itself, just as ugly as ever. On a large site with many workbooks being viewed by many people, viewings will inevitably overlap. People don't necessarily want shared editing, but they do want to be able to click Read-Only. They don't want the program to crash if they accidently open a spreadsheet through Explorer. So its a fairly bad bug really.

I'm really hoping someone can help. We have an issue on our network where Excel (2013) will crash on opening. Here is more detail. It seems to be triggered by those grey rectangular messages that may pop-up at the beginning when you open a file, such as 'need to update links', 'cannot update links due to one being broken', 'password required', or most commonly 'locked for editing by someone else, would you like read-only?', BUT IT NEVER QUITE GETS THIS FAR, so you never see the message itself. (BTW: what frustrates my internet searches is that there has been a lot of recent issues with false Excel file locks. This is not our issue.) Other people genuinely have got the file open, so there is a genuine and appropriate lock. But the second user never gets the chance to click 'read only' and continue. IF THEY OPEN THE FILE FROM WINDOWS EXPLORER (after someone else has already got it open), the Excel 2013 green intro box pops up as normal as the program loads to open the file. But it hangs there. You can use the cross at top right of the green intro box. Then launch Excel again. Nothing. Then again, and message will tell you something like 'Excel cannot be stopped at the moment'. Then you get the choice to restart the program. IF YOU OPEN EXCEL FIRST AND BROWSE TO THE FILE FROM WITHIN PROGRAM then the notification such as 'file locked' opens JUST FINE and there is no problem because you get to click 'read-only' and continue. When trying to open from Explorer, it is almost as if the component of Excel 2013 that will display the grey message box needs to be launched first, but isn't and so the program gets stuck unable to display the message. I have hoped that this, that, or the other update would solve our problems, but it hasn't happened and I need to seek wider advice. Any ideas? We are Win7 x64. We did not have this problem when we had Office 2010, but we also went to a 64bit OS about the same time as we went to Office 2013.

James, Thanks for the clarification about Office 365 support. I had asked my boss whether we had support available, but he gave me the wrong answer initially because he was confused with Office 2013 support. My boss has informed me that he has been through this support before. Initially he dealt with Microsoft first line. He says it was VERY painful. EVENTUALLY he was put through to 2nd line support in the UK, at which point his issue was dealt with very quickly. This makes me very apprehensive because I don't have a long time to jump through hoops with first line.

Michael, You mentioned using a different browser. For specific reasons the users concerned would rather not do that. But yes other browser do work. The user cache is already set to clear on exit, and this has been manually cleared, and so has the credentials vault to no effect. When using IE the 'Windows Security' pop-up comes up. In other browsers what happens is different and you get taken through to a login page. Is this because Internet Explorer supports NTLM? Is that what happens? There is clearly a different process on a non-domain computer (as there is on a domain computer) when using IE versus other browsers. Yes we are using ADFS, but surely that cannot be coming into play on non-domain computers?

James, Yes we are using ADFS for replication. Yes, I am well aware that using a domain joined machine then logged on credentials will be passed through. What you are missing is that I have clearly stated that on most of the NON-DOMAIN JOINED machines the 'Windows Security' box prompts for credentials AND THESE ARE ACCEPTED AND THE USER IS TAKEN THROUGH TO WHERE THEY SHOULD BE. It is only SOME LOCAL ACCOUNTS on some non-domain laptops, and even there InPrivate browsing makes the problem go away. InPrivate browsing is not a full solution, obviously. How can I seek support? I imagine we would have to pay for this?

Michael - same Office 365 domain as everyone else. Please note carefully what I have posted. I am making a very careful distinction between domain users on the one hand, and local laptop accounts on the other hand. The problem has NO CORRELATION to the domain user attempting sign in, BUT COMPLETE correlation to the local laptop account used.

Yes it does work using InPrivate mode. That only reinforces my view that it has cached something erroneous that it will attempt to use in normal mode but not in InPrivate mode. Does anyone have any idea why InPrivate mode would help (once again I must emphasise FOR SPECIFIC USERS OF A NON-DOMAIN LAPTOP ONLY all other scenarios don't have the problem - other local users on that laptop are fine).

On our site we have a small number of people who use non-domain laptops. (There is a particular background to this, these are supplied from outside and this is unlikely to change.) In most cases accessing OWA 365 webmail (we have just gone over to 365) is not a problem. However in a couple of cases you get: "Sorry but we're having trouble signing you in". Error 80041317. Now according to Microsoft's articles, and a lot of ADFS advice (we have recently started using ADFS), this error relates to federation problems. HOWEVER in this case there is merely a problem ON THAT PARTICULAR USER OF THE NON-DOMAIN LAPTOP. The domain user itself does not have a problem if, for example, they use exactly the same approach but just on a different user on the same non-domain laptop. So I would conclude that the problem is on the non-domain laptop. I have tried clearing everything I can think of in Internet Explorer (please suggest anything I may have missed) and also clearing the credentials vault (I think, again if there's a heavier duty way of doing it, or I may have missed something please let me know). It does prompt for login details in the little 'Windows Security' pop-up. However you then go through to the 80041317 page. What is Windows storing, and where is it storing it that is causing this problem, or what do you think could be going on? In summary: no domain users can sign in from that local laptop account, they can all sign in from a different local account on the same laptop.

I am pleased at being helped to understand what was going on with this client. But does anyone have a comment on why VAMT 3 always said 'Activation via KMS server successful' (or similar wording). This was inaccurate and very unhelpful and delayed successful troubleshooting of the problem.

RM Tool: negative. They said we're out of warranty so anything would be chargeable. Not going there, not worth it. Intel tool: I doubt the flag would be changed. This is a security feature for Microsoft, so I expect they would have exerted pressure to make sure it wasn't easy to amend the flag. I see us going down the MAK route. Due to the size of the school it will be a pain, because by the time someone deals with this client again it'll be someone else and we might forget.

I just rang RM hardware support. To give them credit I went straight through to what sounded like second-line support, and they understood the problem within 20 seconds. It transpired that the machine is quite old (2009), and out of warranty. They suggested running a BIOS update (even they knew it was a long shot). There is one on their system online. But do you think any ACPI_SLIC related data would be included?

Norphy, thank you for your reply. I was not aware of the ACPI_SLIC table until you mentioned, so I did some research. I found this: You receive an error message when you try to activate Windows Vista or Windows 7 on a computer that was obtained from an OEM I installed the MGADiag tool on the client, and pasted into notepad as the article says. The relevant section result was: OEM Activation 2.0 Data--> BIOS valid for OA 2.0: no, invalid Windows marker So there we have a non-starter for KMS. I hope this helps someone else.

We have many Win 7 Enterprise clients. As far as I can tell they are all activating successfully with the KMS server. Except one. It refuses. It has been completely rebuilt, including after first being deleted from the AD. And then it does exactly the same thing. We have VAMT 3. I have updated the view from the database, checked the client installed license has the same last digits as the other similar clients successfully activated, then selected Activate>using volume activation. A box pops up in VAMT to tell me that activation with the KMS Server was successful. On closing the box I see underneath that it still says 'out of box grace' against this client. Am I misunderstanding how 'out of box grace' interacts with KMS activation? So I then gave up on VAMT with this client. I went onto the KMS server, and at the command line (its Core, so I had to) ran SLMGR.VBS /dlv. I took a Snipping Tool screenshot of the result. I then went the client and ran SLMGR. It says activation failed. So why did VAMT say it had succeeded? I then went over to the server, and ran SLMGR.VBS /dlv again, to see which line had been incremented. Results on the server were exactly the same, except: 'Requests with License Status Initial grace period' was incremented by 1. I don't understand. Why is this even a line in the output? Surely the job of the KMS server is not to say 'yes this client is in the initial grace period'. To me that's pointless. Surely it should either have requests for activation that are denied, or requests that are accepted. What could be going on with this client? Do I have a misunderstanding about how KMS licensing works vis-à-vis the Initial Grace Period.