SharePoint-tenglar brotna um VPN vegna birtra URL-a

SharePoint-síða opnast um VPN, og fyrsti skjalatengillinn mistekst með nafni sem var aldrei í veffangastikunni. Það bil er allt vandamálið: síðan kom frá einni URL, og þjónustan sniði næstu beiðni frá annarri. Birta URL-in er ákvörðun á þjónsstigi, svo að laga hana á biðlaranum er rangur endinn. Athugaðu hvaða nafn þjónustan skilar áður en þú snertir DNS eða leiðir.

Fyrsta síðan og næsta beiðni nota mismunandi nöfn

Notandi sem nær í þjóninn með vefslóðinni sér vinnandi forsíðu. Skjalatenglar á þeirri síðu eru búnir til út frá URL-inu sem þjónustan telur sig birta, ekki út frá því sem vafrinn sló inn. Ef þau eru mismunandi fer næsti smellur á nafn sem biðlarinn hefur aldrei leyst.

Að slá vefslóðina inn einu sinni lagar ekki hvern myndaðan tengil, og bókamerki á vefslóðina felur vandamálið þar til skjal er opnað.

Auðvelt er að lesa þessa bilun rangt sem VPN-vandamál því hún birtist aðeins eftir að göngin eru notuð. Í raun gerir göngin sitt verk: þau bera beiðnina á nafn sem hefur enga vinnandi leið eða ekkert samsvarandi vottorð. Aðskildu spurningarnar tvær áður en þú breytir hvorri sem er. Önnur er hvert pakkinn fer, hin er hvaða nafn þjónustan valdi að birta.

Fjórar stýringar, eitt nafn

Hvert birt nafn verður að standast fjórar óháðar stýringar. DNS verður að leysa það fyrir raunverulega biðlarann, leiðsögn og aðgangsstefna verða að leyfa leiðina, TLS verður að sannreyna það nafn, og þjónustan verður að vera stillt til að birta það.

Breyting á einni stýringu framkvæmir ekki hinar. Að samþykkja vottorðsviðvörun er ekki viðgerð á nafnaleysingu.

Taflan hér fyrir neðan er röð gátlistans. Stoppaðu á fyrstu línunni sem mistekst, því síðari lagfæring getur ekki bætt upp fyrra bil.

Lestu birtingarlíkanið áður en þú breytir því

Uppsetningar SharePoint Server eru mismunandi. Klassískar vefforrit geta notað varamöppur aðgangs, þar sem innri URL er það sem þjónninn tekur við og opinber URL er það sem hann notar til að sniða tengla. Vefsvæðasöfn með hýsilnafni fara aðra leið og geta, samkvæmt leiðbeiningum Microsoft, ekki notað AAM.

Skipulagsleiðbeiningar Microsoft merkja einnig AAM-eiginleika sem úrelta og mæla með vefsvæðasöfnum með hýsilnafni fyrir nýja skipulagningu. Það gerir uppsetningarlíkanið að spurningu fyrir eiganda þess, ekki sjálfgefnu sem þú bætir.

Ákvarðaðu hvaða líkan er í notkun áður en þú leggur til breytingu á möppun. Að bæta AAM-færslu við uppsetningu með hýsilnafni gerir ekkert, og að bæta einni við klassíska uppsetningu breytir hverjum skilaða tengli í einu. Bæði eru stillingarbreytingar með miklum áhrifum, svo undirbúðu þær í áföngum og hafðu afturköllunaráætlun. Þetta er ekki ráðlegging um að koma gömlum möppunum inn í nútímauppsetningu.

Fylgdu misheppnuðu aðgerðinni, ekki forsíðunni

Skráðu áfangastaðinn sem misheppnuð beiðni notaði í raun, biðlaraforritið, tímann og villuna. Vafri og skjáborðsforrit geta farið mismunandi leiðir í gegnum umboðsþjón, VPN eða auðkenningu að sama skjali.

Vafrinn getur tekist þótt Office-biðlarinn mistakist, og sá munur er vísbending um hvaða samhengi leysir nafnið.

Ef URL-in og netafhendingin virka bæði og þjónustan hafnar aðgerðinni enn, er eftirverandi vandamál á forritastigi. Skjalheimildir og útritunarstaða tilheyra eiganda þjónustunnar, og VPN-leið veitir nettengingu en ekki heimild.

Athugaðu afhendinguna frá upphafi til enda

Keyrðu athuganirnar í röð á biðlaranum sem mistekst: leystu birta nafnið, biddu um síðuna á því nafni og biddu svo um URL skjalsins úr frumkóða síðunnar. Hvert skref einangrar eina stýringu.

Þrjár skipanir ná yfir leysingu, TLS og skjalaleiðina:

nslookup portal.hq.example
curl -sSI https://portal.hq.example/ | head -5
curl -sS -o /dev/null -w "%{http_code}" https://portal.hq.example/sites/team/Doc.aspx

Ef leysing mistekst aðeins í gegnum göngin er split-DNS-stefnan grunaði. Ef TLS mistekst skaltu bera saman nafn vottorðsins við birta nafnið í stað þess að smella í gegn. Ef bæði takast og skjalið mistekst enn, snýst villan ekki lengur um URL-in.