Since I started this blog a few years ago a lot have changed. I moved from Russia to USA, SharePoint sites moved to the cloud in numbers, and a lot of tech landscape has changed significantly. We are working in gig economy, not tied to single place or single employer, we are jumping from one technology to another, adapting to ever changing requirements. And while my focus is still mostly on SharePoint Server on-premises as my current client is still waiting to move, my own learning focus has shifted to cloud and Office 365. I’ve also started to build up my home network with the ultimate goal of running a few services on my own and not to rely on cloud service providers. Inevitably, the content that I’d like to post in my blog will be about more broad set of topics.
So it’s time to move away from ProSharePoint.Ru. It’s a nice name, but the blog is not in Russian and not specific to Russian audience, and it’s not only about SharePoint anymore. I wanted to give this blog a new name that will be more generic to and relevant to broader set of topics, and get rid of country reference in the process.
It’s been no posts for a while, I know, but hopefully this will change and new name will act as a catalyst. I’ll keep ProSharePoint.ru available for about a year or so from now, so if you have some links to my blog, you should update it.
Ok, just installed January 2018 CU on SharePoint 2013 farm which was not patched since SP1 before that. It seems the bug from one of the security updates introduced in March 2015 is still there and ruins InfoPath forms.
Exciting news here – ProSharePoint.ru is now Brave Verified Publisher. I even got a shiny referral badge. So if you want to have some privacy and much less annoying ads on the web (and not necessarily by blocking them) you ought to try Brave browser!
Disclaimer: I’m not receiving any money or other compensation for this post. But I will get about 5 USD in BAT tokens for everyone who will use my referral link and do the right thing switching to Brave and using it at least for 30 days.
Now I’ll tell you how this works and why I chose to switch from Google Chrome to Brave and why I recommend you to do the same (it’s not because of referral money).Reading Time: 10minutes
SharePoint patching is always tricky. Difficult to test, difficult to roll back in case of issues, you name it. And every SharePoint pro has the own way to do patching which has been proved reliable and efficient. But now we can rely not only on our own experience and blogs like this one. We have a source of sacred knowledge, passed down from Microsoft itself. Common, grab it faster from Technet Gallery: SharePoint Build to Build Update Playbook
If you are still reading, here is my opinion on this playbook:
Having any playbook is much better than having no playbook at all. So this will definitely help you if you don’t have a formal approach to updating SharePoint.
Since every SharePoint deployment is unique, there is no “one size fits all” approach. This playbook requires some adaptation for your customers’ SharePoint deployment. Worth mentioning that the playbook is not version-specific. Some tasks are not applicable for SharePoint 2010, like the one related to distributed cache.
I would say that many of the tasks mentioned in the playbook can be and should be scripted. For instance, preparation steps like testing content DBs or verifying that there is no verbose logging enabled can be scripted easily.
Sometimes we just need to do something dumb. For instance, recently I have changed default DNS settings of network adapter on client OS (Windows Server 2016) side of my Azure VM. Next moment, the RDP connection has failed and I couldn’t reconnect again.
The first idea was to replace NIC to another one, which should be recognized by client OS as a new one with default “auto” DNS settings. Well, actually the first idea was to reboot the VM, but it didn’t help.
So let’s see how to replace an existing NIC on Azure VM.
You are trying to create a new managed account and what you get is either:
New-SPManagedAccount : Some or all identity references could not be translated error when you try to do it with New-SPManagedAccount PowerShell cmdlet
The specified user <AccountName> could not be found. Some or all identity references could not be translated when you try to do it in Central Administration GUI
What to check to pinpoint the issue
If the account name you are adding as managed is longer than 20 symbols
The reason why it doesn’t work
In this post I describe the case when an account has a name longer than 20 symbols (however, there might be other reasons for that error, such as deleted AD account). This easily can happen if you use descriptive account names, ruled by naming conventions or common sense.
Keep reading if you want to know what’s going on here or skip description right to the solutions part.
Every SharePoint admin have heard or read at least once that it is a bad practice to assign unique permissions to individual items in SharePoint. Yes, it is not good for content manageability, but why else it can be bad?
As the title says it harms performance of your SharePoint. So if you have performance issues keep reading to know if it is related to permissions.
Emails sent to SharePoint library address don’t reach destination.
No error message returns to sender
What to check to identify the issue
Incoming email “Drop” folder on SharePoint WFE – all missing emails should be there, awaiting to be picked up by SharePoint
ULS logs has the following error with “E-mail” category:
The Incoming E-Mail service has completed a batch. The elapsed time was 00:00:00.0156241. The service processed 4 message(s) in total. Errors occurred processing 4 message(s): Message ID: Message ID: Message ID: Message ID:
It was hard to find it because of misleading info, so I post it here.
Update: the issue was fixed in May 2015 CU. Keep reading if you cannot install this CU, need temporary workaround or you are just naturally curious.
SharePoint 2010 Administration service cannot start after the server boot-up.
Windows event log contains the following error:
The service did not respond to the start or control request in a timely fashion. Error (7000, 7009)
SharePoint 2010 Administration service cannot be started manually in this case
The issue is caused by automatic check for revoked certificates on the start of any .Net executable (SharePoint 2010 Administration service executable WSSAdmin.exe in this case). This check is performed by download an untrusted and trusted certificate trust lists (CTLs) from the Windows Update web service. If this download is not possible for some reason, service can fail to start because of the timeout. You can find some additional details in the KB2677070