Jump to content

Recommended Posts

Posted

Hi All, Im having major issues installing SIMS on win 10 1709 - SOLUS3 complains that it cant connect like a f/w issue - with this version there appears to be no way in stopping the firewall service to test this. I have inherited a network where the firewall for clients is currently switched off.

 

anyone else had any issues?

 

Thanks

 

Brian

Posted

Try opening these ports on Windows Defender Firewall for your subnet:

 

52965:TCP (SIMS Solus-3-DS)

52966:TCP (SIMS Solus-3-Agent)

8739:TCP (SIMS Solus-3-Agent-UI)

 

And allowing this program:

C:\Program Files\Solus3\AgentService\Sims.Solus3.Agent.UI.exe

  • Thanks 1
Posted
Its really odd, I look after 3 primary schools and a secondary school - the client firewalls are switched off on domain policy. Only 1 school I look after has this issue with 1709 - they all have the same firewall settings. I'm not back to the school that has the issue until next week. I may have to create a test OU with a test firewall rule with those rules in and see if i can get it to work - SOLUS3 says it cannot connect to the PC's on 1709 but can on 1703 there
Posted
Not teaching you to suck eggs or anything but I found that I had to do a ipconfig /flushdns on the Solus server when I upgraded our workstations to 1709. I also had to remove the workstation from Solus and re-add.
Posted
Not teaching you to suck eggs or anything but I found that I had to do a ipconfig /flushdns on the Solus server when I upgraded our workstations to 1709. I also had to remove the workstation from Solus and re-add.

 

This one's a brand new PC not an upgrade unfortunetly so it never existed before

Posted (edited)

even with the firewall rules in place (which they were, I still cannot push SIMS to 1709 machines) interestingly on any 1709 machine from the server I cannot get to the c$ of the machine for example \\ITTEST\c$ however on a 1703 machine I can get to it.

I can also get to \\ITTEST\c$ from the server if it was 1703. this is strange behaviour

 

I can also see the c$ share if i go 1709 to 1709 \\ITTEST\c$

 

so this makes me think its the server having issues with 1709

Edited by edubri
Posted
Is the firewall enabled on the workstation. By default we disable the domain firewall connection.

 

domain firewall is off and client firewall off - the thing I cant get my head around is why can the server see the c$ drive on a win 10 1703 machine but not a 1709 machine and yet a 1703 or 1709 machine can see the c$ drives or either

Posted

File Sharing.JPG

 

Make sure File sharing and Network discovery are ticked in Network and Sharing center, Advanced sharing settings. I think in 1709 by default they are off even with the firewall disabled.

Posted
[ATTACH=CONFIG]46094[/ATTACH]

 

Make sure File sharing and Network discovery are ticked in Network and Sharing center, Advanced sharing settings. I think in 1709 by default they are off even with the firewall disabled.

 

all ticked - still no joy - its such an odd problem the server isn't able to see the c$ of 1709 clients (server is 2012 R2, latest updates, and newest GP's for 1709)

Posted

And this:

 

Long version:

Network Discovery and File and Printer Sharing is turned on. Firewall configured correctly (and I would briefly disable it and try again to see if it worked, nope). Nothing strange about running/stopped services compared to a PC that it works on.

Strangely, running "netstat -a" in a command prompt shows localhost is listening on port 445, but when I scan it with nmap (Zenmap on Windows) with "nmap -p 445 ", it says that port is closed - even with the firewall disabled. Hmm.

This pointed me to something wrong with the adapter settings. Lo and behold, even though I had "File and Printer Sharing" turned on in Windows, the "File and Printer Sharing for Microsoft Networks" client for the active network adapter was turned off.

Posted

 

Thanks for link

 

the last line of that link was a massive clue to the issue!

 

"SMB1 is uninstalled by default in latest Windows 10 and Windows Server configurations. For more information see SMBv1 is not installed by default in Windows 10 Fall Creators Update and Windows Server, version 1709."

 

As soon as I read that I knew what the issue was - - needed to add feature SMB1 and then the server was able to see c$ on the clients

 

 

Thanks once again for your help, I have lots of happy teachers again using SIMS !

Posted
No probs. We are running 1709 on 800 workstations and Server 2016 so knew it must have been something to do with the new security implications.
  • 2 months later...

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...