We're working on an implementation of DirectAccess using Windows Server 2012 R2.
The DA server is a single NIC behind the firewall with TCP/443 forwarded for IPHTTPS.
During the initial testing/setup, we set it up strictly for Windows 8.1 clients, using the username/password (computer account) to authenticate. Everything worked beautifully.
Wanting to extend the testing to Windows 7 clients, we configured DA to use certificates for authentication. We have an internal PKI infrastructure that has worked properly for everything else we've needed it for during the last 2 years.
Windows 7 clients, with the DirectAccess Connectivity Assistant, connect and work beautifully. However, Windows 8.1 clients cannot.
We've checked the certificates and all seems good. Using the DirectAccess Troubleshooter, we see that it connects successfully to the DA IPHTTPS URL, however it can't access any internal resources. We can ping the internal DCE addresses x:y:z::1 & x:y:z::2 that it is my understanding are the DA server inside our network.
Are there any additional tools for troubleshooting this? Can anyone point me in the right direction to determine why only Win8 clients won't connect with certificates?
The initial getting started wizard in DA allows Windows 8 / 8.1 to connect using Kerberos Proxy (no certs). A full blown install using PKI mandates that all clients use certificates. Deploy the Computer certs to the Windows 8 / 8.1 and you will be fine.
Reference - http://technet.microsoft.com/en-gb/windows/dn197886.aspx
How does DirectAccess in Windows 8 and Windows Server 2012 simplify deployment?
In earlier versions of Windows Server, a PKI was required to deploy DirectAccess. DirectAccess used the PKI for server and client certificate-based authentication. Now Windows 8 sends client authentication requests by using a Kerberos proxy service running on the DirectAccess server. The Kerberos proxy service sends requests to domain controllers on behalf of the client. As a result, for simple deployments a PKI is not required to deploy DirectAccess, and IT administrator can use the Getting Started Wizard to configure DirectAccess in a few easy steps. For more complex deployment scenarios, PKI is still required.
It would help if you can present some graphical representations of your problems 'cause every response to your question would only be assumptions.
Troubleshoot as follows:
Check to make sure the windows client is an Enterprise edition
If point 1 above is true, run the 'get-DaConnectionstatus' command on Powershell to see if the client can determine its location, otherwise get a windows enterprise edition.
3.If both point 1 and 2 are true then check to make sure your group policies are well configured. Remember to separate the security groups for windows 7 and windows 8 clients.
Related
So what I'm trying to accomplish here is basically just like an SQL server connection, I want to connect SSAS instance from another computer in the same network using a login account. Things I search online mostly deviates from this a lot at some point. What I need to know is what configurations should I do on SSAS services to enable this? How to crate a new login account (the system I am connecting from is not windows based so no windows authentication) and basically how to build connection string?
I have checked some documents of windows but mostly I am lost.
SSAS clients support NTLM, Kerberos, and (only with the data pump) HTTP Basic and Anonymous auth.
Of those Kerberos and HTTP Basic (with the data pump) are usable on non-Windows platforms. But I don't know if ADOMD.NET for .NET Core (the only non-Windows driver) supports Kerberos on non-Windows platforms.
How do I access a smartcard that is locally attached to a Windows Server 2008R2 in a self written Windows service that is running on that server?
NB: I can access the same smartcard when I start the service as normal Windows 10 application from the command line.
You did not provide enough information about the problem you are experiencing but changing service identity to LocalService and not using RDP usually helps.
Trying to setup an ODBC connection for UPS to access our SQL server, from our shipping client computer.
I have scoured as much as I can an ran across:
runas /netonly /user:domain\account "c:\windows\system32\odbcad32.exe"
Now, using this method, on my current client computer, I was able to setup an odbc connection successfully using SQL Native Client 11 (5058). I am using Win 10. Our shipping computer, with multiple manifest systems on it, is still using Win 7, but otherwise is setup the same on the domain.
Using the same process as above, the connection ultimately times out, and states that the server is not online/not available/not allowing remote connections.
Is there a step I'm missing? Both clients have same rules for firewall, both are using the same user/password in the runas cmd. The only difference between the two clients is Win 10 vs. Win 7, and the current logged in user is different (but that shouldn't matter with the runas cmd?)
Thanks!
So after several days/hours of trying various solutions and suggestions from all over the interwebs, I came across this solution/tips.
In SQL Server Configuration, checking the network configuration protocols/clients/aliases. In my case, there was an aliases established for 32-bit, and not 64-bit. I disabled the 32-bit one.
I then found suggestions to us the ip (which I had tried in the past, with no success), but this time, after ensuring all the tcp/ip protocols were enabled and the 32-bit aliases was disabled, I was able to connect the 32-bit to the 64-bit SQL server, using the xxx.xxx.xxx.xxx address of the server.
Test came back successful!
I'm trying to test a migration of moving a BizTalk SQL Server from one server to another. Here are the details.
Currently it was all on a single server in a dev environment, BizTalk SQL, SSO and BizTalk runtime all on one server. It is a Windows 2008 R2 server with SQL Server 2008 R2.
What I want to do is split out the SSO Master secret server and BizTalk databases to a Windows Server 2012/SQL Server 2012 setup. So far I got SSO all setup on the new SQL server. I configured just the SSO portion on that server and all went well.
I then unconfigured the existing BizTalk Runtime and then went to configure again, using the new Windows/SQL Server/SSO in the configuration process.
All goes well up to the point where it tries to configure the BizTalk runtime. That being said all the database are created, SSODB, BizTalkMessageBoxDb, all of them. But when it goes to configure BizTalk Runtime, it hangs for a while and several of the following errors show up in both of the Server's logs:
Could not access the SSO database. If this condition persists, the SSO service will go offline.
Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding..
SQL Error code: 0xFFFFFFFE
It shows up in the SQL/SSO servers logs first, then the Runtime server a few seconds later. Eventually the configuration times out and fails. I believe it's permissions related, but I can't seem to figure out what it would be.
Questions:
what permissions do I need to review?
would the fact that the new server is Windows 2012/SQL 2012 while the runtime server is Windows 2008 be an issue?
is there any way I can get more details on this error?
Edit to add both DTCPing and DTCTester pass with flying colours and I can connect to SQL via SSMS from the server. Firewall has been completely disabled for now in order to eliminate that as well.
How were your service accounts configured in the first environment? Typically a single DEV environment with everything on one box can be done by using a local account on that server. If you now split out your SSO onto another server (it doesn't matter if it's W2K12 instead of W2K8), you are going to have to switch your service account(s) and groups for BizTalk to Domain accounts.
In a multicomputer environment, BizTalk Server supports only domain groups and domain service accounts. Domain groups include Domain Local groups (not recommended), Global groups, and Universal groups. Built-in accounts such as NT AUTHORITY\LOCAL SERVICE, NT AUTHORITY\NETWORK SERVICE, NT AUTHORITY\SERVICE, NT AUTHORITY\SYSTEM, and Everyone are not supported if you want to configure BTS in a multicomputer environment.
Make sure your SSO is running as a domain account, and a member of an SSO Administrators domain group - and ensure this domain account/group combo is configured for the SSO system on the SQL server (instead of local accounts):
After that the SSO system you join from the BizTalk Server before configuring the runtime on BizTalk Server usually needs to be configured with the same domain service account for SSO:
I'm developing a WCF webservice, but when it loads via visual studio in the built in server (Cassini) I cannot access it anyway except via localhost on that machine. I would like to try it with connections from other machines as well though... what's the best way to do this without installing IIS on my box (I can't...stupid system corporate policies prevent it).
You might be able to use / install IIS Express (see this link) without administrative privileges. However sadly Cassini does not allow remote connections.
If I am not mistaken, you should install IIS. Cassini does not support remote connections.