A customer of ours is using a kind of sharepoint (not sharepoint) -a document repository- that, for what I saw, uses webdav.
There are two terminal servers, one of them is Windows 2008 R2 Datacenter v6.1 build 7601, Office 2016, and Internet Explorer 10.0.9200.17609IS. They couldn't access anything at all, they went as far clicking "edit" on the site and then Word they that he's sorry because he couldn't open the document.
I've fixed that, I added the site to the Trusted Sites list, and disabled SSL 3.0 and TLS 1.0. Local admins can open and update documents. Non admin users can open the document but not update it, and by can't I mean that Word opens the document in read-only mode and any attempt to switch to read-write will save the document in the local computer.
Now, the other server, Windows Server 2012 R2 version 6.3 build 9600, Internet Explorer 11.0.9600.19867, the former fix did the trick for both admins and non-admins.
Does anyone know where to look?
Thanks,
Max
Related
I have installed MongoDB (3.0.15) in my local Sitecore 8.1 (initial Release) instance and have enabled the following setting/config
Enabled "Xdb.Enabledand" and "Xdb.Tracking.Enabled" in Sitecore.xdb.config
Enabled "enableTracking" for all my sites in mysitedefinition.config
Enabled Sitecore.MvcAnalytics.config file
Disabled all the xDBCloud related files
Added mongodb connection strings in connectionstrings.config
Also started mongod service from commend prompt and made my session timeout is 1 minute instead of 20 minute in web.config
after all I have made few visits to my site pages i.e home page,about us,products,new pages but interaction data does not appear in the collection database for the visited pages (analytics and tracking.live databases created)
(All my pages have the identification tag & have license for mongodb)
Please suggest how to solve this issue/how verify my collection db working?
Also I have configured processing/reporting servers in my local instance but contact and history collection databases not appeared in xDB- please suggest
Thanks,
Karthik
I followed the documentation on https://support.office.com/en-ie/article/Deploy-Office-Add-ins-in-the-Office-365-Admin-Center-737e8c86-be63-44d7-bf02-492fa7cd9c3f to publish a created addin to our users. Unfortunately it is not showing up when users check out their Add Inns ( I see a caption Office 365 / Managed by admin but no selectable addin.
I tried:
Restarted MS Word
Logging in and out from MS Word does not help.
Removing the add in and adding again (through file or URL both not work)
Any ideas?
We seem to have the same issue; If you intercept the HTTPS traffic (by Fiddler for instance), do you see a 500 response to the 'POST /ews/exchange.asmx' with the body containing 'GetPrivateCatalogAddIns'?
So far, this seems to be an issue with Exchange internals. We've been trying to get into contact with Microsoft about the issue. Here you can find the StackOverflow issue we have filed, and Here you can find the question on the MS fora.
EDIT: It was confirmed that this was indeed an internal problem. We have removed our deployed plug-ins and added them again. The call now responds with a 200 and everything seems to be working again.
Unfortunately, we also found out that there is an issue with the Add-in registration interface in the Office 365 Admin Centre, as people who are not full administrator but User management administrator instead can no longer upload Add-ins due to an Exchange credential error. A Office 365 Administrator however can and this seems to be working with us.
Today I had a support engineer of Microsoft on the phone about my case and they resolved the issue. I can deploy add-ins again.
When trying to configure the TFS 2010 backup using the TFS Power Tools I kept running into teh following error message:
Account TFS\tfsadmin failed to create backups using path \\tfs-xxxxxxx.local\TFSBackups
The strange thin is that TFS\TFSAdmin has full permissions on both share and file system and that the share path doesn't contain any spaces (thanks for MSDN forums for pointing that out).
I tried backing up through the SQL Server Management Studio, and sure, there the backups fail too.
It turns out that while the backup job is started using the account specified in the Create Backup Wizard of the TFS Power Tools, SQL Server will try to write the files to the share using its own service account.
So in addition to whomever needs access to the share, you need to add the service account running SQL Server to that share as well. In this case it was running under NETWORK SERVICE, so adding MACHINENAME$ to the share's list of permitted users did wonders.
Typically I remote into a machine with IP Address 00.00.00.00 and then I have an account in a domain, let's call it myspecialaccount\firstname.lastname.
Then I use Windows auth to connect to SQL Server instance for example:
ABCLACSQLC123\DEV04A
So my question is HOW can I connect from my laptop through SSMS directly to the machine (pending ports are open etc..)
In order to use Windows Authentication, you'd have to add the credentials you use to login to the laptop as a "Login" to the SQL Server. That can only be done if
You login to your laptop with a domain user and
The user is in the same domain in which your SQL Server instance resides
Otherwise, you have no choice but to use SQL Server Authentication.
In this case, you login to your laptop with a user in "Corp" domain, but SQL Server instance is in "Services" domain. So it won't work. Unless I think both domains are part of the same Forest.
Look at this answer : https://stackoverflow.com/a/1615431/3317709. There is no trick to login, unless you get rid of the "Network related..." error. If you are getting this error, SSMS is not even able to find your server let alone logging into it. Once you get "Login failed..." error, from that point, we can tinker and try to get thru using your windows auth.
Try creating a shortcut to runas.exe, pointing to SSMS.
C:\Windows\System32\runas.exe /netonly /user:myspecialaccount\firstname.lastname "C:\Program Files (x86)\Microsoft SQL Server\100\Tools\Binn\VSShell\Common7\IDE\Ssms.exe"
(The path to your SSMS exe may vary.)
When you double-click the shortcut, this will open up SSMS. You should then be able to connect to your instance (ABCLACSQLC123\DEV04A) as if it were on your local machine.
See here for more info on the runas command: https://technet.microsoft.com/en-us/library/cc771525.aspx
Install SQL Server Management Studio Express on your laptop. Microsoft has made the download link obscenely hard to find on their own site, but I did manage to find it here. Download the one for your system, probably x64.
Installation isn't much easier. Once everything is extracted, run the program, and switch to the installation tab, and choose "Standalone installation or add new features". Continue along the installation, and just install the management tools.
Once installed and running, use the Connect to Server dialog (it should open when you start the program, but if it doesn't, it's the first option under the File tab), and target wherever you want to connect (IP or server name should both work). If your laptop also authenticates to the same server that handles Windows authentication for your database, you can use Windows authentication, otherwise, you'll have to create a SQL Server account to use for login.
Recently migrated an ASP.NET application from an old server to a new server
Both servers have the Same OS Windows Server 2008 R2 Standard
IIS 7.5 on both servers
SQL Server 2008 R2
The only difference is the amount of RAM and CPU speed
I have gone the server point to point and cannot find any differences.
I had a developer look at the code and he says its not the code
On the old server the website loads fine on the new server I get an error when browsing the website via domain name
Microsoft SQL Server Native Client 10.0 error '80040e4d'
Login failed for user 'NT AUTHORITY\IUSR'.
/lib/SQLHelper.asp, line 134
I cannot find anywhere that NT AUTHORITY\IUSR is being told to attempt to log in. Im thinking it is some kind of default. I have googled every line of the error trying to find a resolve and have been basically flipping switches to try to find an answer, nothing i have tried provides any good results.
Is there a setting in the deep dark belly of windows that im not checking?
'NT AUTHORITY\IUSR' is used by IIS as the account for anonymous users. This means that IIS is using passing through the authentication information to the SQL server rather than using a specified user account.
In most situations you would either have specified an account to be used in the connection string or disabled anonymous access to ensure that the account passed through is a authenticated user account.
It is possible to give the IUSR account permissions on the SQL Server.
Try looking at this article as it may give you some assistance The error "Login failed for user 'NT AUTHORITY\IUSR'" in ASP.NET and SQL Server 2008