Skip to main content

Since I migrated Jamf to a Windows 2019 server two weeks ago, I have been troubleshooting the primary distribution point. The distribution point and jamf server are running on the same VM. I have tried and failed with https, probably because of the same root cause... so I am trying to simplify the issue by first troubleshooting the SMB dist point problem.

I am able to mount the share both from Windows and Mac clients using the jamf service accounts. I have been able to validate that the accounts work as-should... one read-only, the other read-write. I don't know what the jamf binary and jamf admin do differently to mount the distribution point, but both fail without any helpful messages.

I'm wondering if any of you have had a similar experience, and whether you have been able to locate your root cause and resolve. I have a packet capture out to Jamf support right now. I have been working with them for two weeks without resolution. I just re-built my Jamf server a second time with the same results.

Thank you

A few years back, had the same issue when we migrated/updated our on-premise server. If I recall, it ended up being the settings on Jamf Pro (Settings, Server, File share distribution points). SMB.

It had something to do with the username needing a "\\" in front of the username.

Or maybe both a "." and "\\".

Example: username: .\\caspershare

Once we played with that, it worked. I can't recall all the details, but if I come across the articles, I'll post.

A few years back, had the same issue when we migrated/updated our on-premise server. If I recall, it ended up being the settings on Jamf Pro (Settings, Server, File share distribution points). SMB.

It had something to do with the username needing a "\\" in front of the username.

Or maybe both a "." and "\\".

Example: username: .\\caspershare

Once we played with that, it worked. I can't recall all the details, but if I come across the articles, I'll post.


I'll update this and mark it solved later this week after testing some more scenarios. What I found just now, which is weird because it was not setup this way on the old server... everything works when I use the legacy short domain name

Nice.

I'll update this and mark it solved later this week after testing some more scenarios. What I found just now, which is weird because it was not setup this way on the old server... everything works when I use the legacy short domain name


This was the resolution... I need to take a look into why this is the case... but maybe this will help someone in the future.

Curious, was the Workgroup or Domain name beyond 20 characters before you switched to the short name?

 

Curious, was the Workgroup or Domain name beyond 20 characters before you switched to the short name?

 


it is exactly 20 chars

I fixed this by removing the domain suffix from our domain name in the SMB distribution point settings, and just used the simple AD name for the domain, e.g.: pretendco instead of pretendco.com .  This started to be an issue in Monterey, though I'm not sure why.

Reply


Terms & ConditionsCookie settings