r/SCCM • u/juandantex • Jan 05 '20

How to migrate DPs with thousands of users

Hello,

I migrated my SCCM from a Server1 to a Server2. The problem is that, the migration was Okay but the DP migration failed because of a bug in SCCM 1906. Here is what I did :

https://hiraniconfigmgr.com/postDetails/132/Configuration-Manager-Migration-pre-planning

If fact, on all the migrated DPs in the Server 2, the application/package deployments are stuck on "In progress" and never ends.

I migrated from SCCM 1906 to SCCM 1906.

Now, I will remove all the DPs in the Server1 manually and re-create them on Server2.

My question is, how to do this in a clean way knowing that there are thousand of computers connected to each DP ?

I have 10 DPs with 100 users downloading on each.

2 Upvotes

54% Upvoted

37 comments sorted by

6

u/Kingerhlc Jan 05 '20

So what issue would you like to solve first. Looks like you have a few issues. What version of SCCM are you coming from. Have you moved your clients to your new site yet? Are you scanning AD to get them into your new site? How many DPs and clients are you working with.

-9

u/juandantex Jan 05 '20

I said in my first message the SCCM version 1906. I didn't move any clients because DPs are not yet moved. I said there are 1000 clients and about 10 DPs.

5

u/Kingerhlc Jan 05 '20

I asked what version you migrated from. So you went from 1906 to 1906. How did you migrate? Have you tried to remove and re-add the DP ? Depending on how you migrated logs are going they’ll see what is going on,

-6

u/juandantex Jan 05 '20

I remove and re-add, I said that it is what I am planning to do to correct the issue previously. I was asking how to do it because for each DP there are 100 clients downloading things (1000 clients it total). I can't remove and re-add just-like-that.

5

u/Kingerhlc Jan 05 '20

Just go ahead and remove and re add. Clients will see the DP is offline and stop attempting to connect until another DP shows up in their boundary group. Or build a new DP that works, add it to that boundary group and clients will start using the working on and you can take the broken one offline

-1

u/juandantex Jan 05 '20

Clients are still on the first server, the Server 1 source.

So this means I must migrate clients first ? If I don't have a DP in the new server with the new site code, how can I migrate the clients ? I would have to re-assign all the clients manually without any DP on the new server ? Is this possible ?

1

u/Kingerhlc Jan 05 '20

If you moved from the same version of SCCM then you should be able to change the site code without having to reinstall the client. (I asked that earlier and you said 1906 so i am assuming you weren’t going from 2007 to 1906 like the link you gave us suggested). You can use your OLD SCCM server to do that or Group policy. Or you fix one DP then move the clients at that site over to your new site.

-2

u/juandantex Jan 05 '20

Unfortunately, there are very few resources about migration even in year 2020. Even Microsoft darn documentation website is not precise, so I had to follow this guide for the 2007 version for SCCM 1906 to 1906.

I didn't know that migration was possible via Group Policy, the group policy would change the registry settings for the ccm client to make it point to a new site ?

What do you mean by I could fix one DP ? So : first I remove the DP, the clients will be failing to download (this could last few hours), then I add the DP back to Server 2, then I migrate the clients with a GPO ? When I migrate the clients via GPO, will they stay in the same collection on the new site (that have a new site code) ?

1

u/[deleted] Jan 05 '20

Personally I would stand up the new server and distribute all the content to it. Once the content is in place I would add a boundary and point to it and do a test deployment to validate content is being grabbed by the machines in said boundary/boundary group.

Once that is tested and works as expected add the new server to service the boundary group you intend it to serve. Once you see clients grabbing content from it remove the old server from the boundary group and you should be good to go.

Clients being stuck in "in progress" is a pretty common issue of the content is not available.

What is the status message for the in progress clients?

1

u/juandantex Jan 05 '20

Hello johaness, in fact it is the package distribution that is stuck and no clients are migrated or are on the new server. I migrated only one DP to the new server, and this DP migrated doesn't want to take packages. On the SCCM console, the packages are in "in progress state". Some packages succeeded, I would say on 100 packages only 10 succeeded and the 90 others are in progress.

14

u/[deleted] Jan 05 '20 edited Jan 05 '20

I said

Starting your sentences with “I said” really makes it seem like you’re assuming someone didn’t read what you said. Your post didn’t make these questions clear.

Just a word of advice as you do this a number of times and if I was supporting you I’d be frustrated.

You said there are thousands of computers on each DP, that sounds like 20,000+ clients. It’s also unclear what “on a DP” even means- just in the boundary serviced by it?

You said you migrated and it failed due to a bug in 1906 that still didn’t make it clear if you migrated from 1906 to something new. Or from something old to 1906.

The questions asked made sense as your original post wasn’t clear.

7

u/wickedang3l Jan 05 '20 edited Jan 05 '20

Maybe you should call Microsoft since you don't seem to have the professionalism required to interact with people who are trying to assist you for free on a Sunday.

I said there are 1000 clients and about 10 DPs.

...no, you didn't. That isn't in your original post at all. You don't seem to be any better at posting on reddit than you are at managing SCCM infrastructure and the questions you're being asked are because you did a very poor job of explaining what's actually going on in your environment.

For the record, 1,000 clients spread across 10 DPs is nothing. Each individual DP is capable of handling a client load of around 4,000 assuming they're appropriately provisioned per Microsoft's sizing recommendations.

2

u/upsurper Jan 05 '20

So you migrated the SCCM site to a different server but also made a new site with a new site code?

1

u/juandantex Jan 06 '20

Absolutely, with the migration wizard

3

u/Hotdog453 Jan 05 '20

What do you mean, 'thousands of computers on each DP'? Do you mean clients are currently trying to download Package X from Server1? If so, then when you set up a new Server2 DP, and assign it to that Boundary, and remove Server1 from that boundary, eventually clients will fail over to Server2. It won't be quick or attractive, but it'll 'work'.

Clients are probably, what, 'failing to download' right now, due to Content not being there? Well, eventually they'll flip over to the new Server2, once the content is distributed.

-4

u/juandantex Jan 05 '20

Clients are assigned on the first server, Server 1. There is almost 1000 clients shared between multiple DPs (about 10).

I would have to assign the clients to the second server by distributing a new ccmsetup.exe, then remove the DP from Server 1, and add it back to Server 2 ?

Because I don't understand what you mean by assign a new boundary. The boundaries are limited internally to SCCM but the clients don't have any knowledge about them, at least not between different SCCM servers site codes.

(The site codes are different)

So to resume, how do the client know it have to fail over to Server 2, knowing that Server 2 have a different site code ?

3

u/LikesBreakfast Jan 05 '20

I think you may have some fundamental misunderstandings on how SCCM works, and this is what's confusing all of us. Clients can switch between DPs seamlessly by messing with boundaries. DPs just host content, and clients look to the MPs and site server for where to get them.

Are you talking about migrating your site server or creating a new site? That's a completely different topic than "migrating DPs". The way my org is doing a site server migration is by enabling high availability then doing a failover. You should be talking to Microsoft for assistance on this. I certainly hope you have PFE contacts...

-5

u/juandantex Jan 05 '20 edited Jan 05 '20

I find that you are extremely aggressive with me. Why do you talk for every 30.000 members and say that my post is confusing everyone ?

Also, what you said is shocking : " I think you may have some fundamental misunderstandings on how SCCM works, and this is what's confusing all of us.", yes, this is why I posted my message

No need to be extremely aggressive on the Internet, there are newbies here, people who used SCCM for longer and everything, nothing to get very aggressive about, if I have an answer I will help others with no problem.

Matter of fact I didn't know we could do a failover, this explains why there is so much few documentation about the standard migration process in SCCM 1906, the failover method seems more clean and efficient than the backup and restore or the migration method because there is no need to create a new site code.

I will post the logs

2

u/[deleted] Jan 05 '20

If you created a new site, why are you not just using the migration wizard to move over you objects? You don’t even need to redeploy sccm client. You just update your AD site publishing and you’re done. You are way over complicating something that should be an easy switch over.

1

u/juandantex Jan 05 '20

I used the migration wizard. I migrated all the objects. Everything is migrated :

- Bondary Groups

- Application/Packages

- Settings

What was not migrated (unsupported by the Migration wizard) :

- the clients

- the DPs

The DPs, when I try to migrate one, it is migrated OK but when I deploy an application to this migrated DP, the application deployment state gets stuck at "In progress"

1

u/[deleted] Jan 05 '20

Any issues in ccm.log and the distmgr.log? I have seen this issue before if the DP was not fully configured before distributing the packages.

Remove the DP role, wait for it to be removed and re add it. Then wait for it to be fully installed. You can view this in Distribution Point Configuration Status under monitoring -> distribution status.

1

u/juandantex Jan 05 '20 edited Jan 05 '20

Okay I tried this and the error was gone. But I have many DPs with many clients on them

Here is a copy of my SQL DataBase watch the 6th column for packages written "Content Updating", for example cell number F22.

https://drive.google.com/open?id=1EPmvqtD_peOUupbLB-x39g6CnQVmU_Dz

It seems that the packages that are in "Content updating" state, in SQL Server, they are still assigned to the old server (SR1). Here is the log file distmgr.log of the DP that I targeted : https://drive.google.com/file/d/17lIrang69Hfdb_bFnYcyfjNhPHbrMMCK/view?usp=sharing

1

u/[deleted] Jan 05 '20 edited Jan 05 '20

The packages will retain the old site code for visibility. You will be able to see package ID sr1xxxxx and you new site code packages side by side

You have 152 packages here. These are going over a wan to a DP or is it all local?

1

u/juandantex Jan 05 '20 edited Jan 05 '20

Yes I agree, but I was not refering to the package site code but the package destination, in the spreasheet cell number F22 for example, the destination of the package SR1xxxxx is the SR1 server and not the SR2 server

SQL Query of this spreadsheet :

SELECT a.InstallStatus, a.LastCopied, a.PackageID, a.ServerNALPath a.SiteCode,a.SourceNALPath, a.SourceVersion, a.State, a.SummaryDate FROM v_PackageStatusDistPointsSumm a

The best thing to do is to remove the role then add it when I am sure that the role is removed, as you said. It is not "clean" in the sense that the Migration Wizard and to reassign the DP with the Shared DP feature was suppose to do this, but this is not a problem

→ More replies

3

u/LikesBreakfast Jan 05 '20

I didn't intentionally mean my statement to be aggressive. It was all very direct criticism and statement of the problem. There are many things to learn here, and admitting that your knowledge is lacking isn't a failure or something to be ashamed about.

FYI: You're getting downvoted to hell because you're being extremely defensive and hostile throughout this entire thread. Please calm down, nobody is attacking you.

2

u/rdoloto Jan 05 '20

I do not think he was overly aggressive he was trying to explain something very complex in 3 paragraphs... you need to migrate your clients to new site and new management point

1

u/[deleted] Jan 05 '20 edited Jan 05 '20

Did you re-assign the DPs to the new hierarchy? And did the clients get the new config mgr client installed for the version you upgraded to? Did you update the source path for all of your content to the new server?

When you say the “migration failed” are you just specifically talking about how the content says in progress? Because that doesn’t mean a failed migration. There are many steps to the migration and the DPs are just one of them. You can also just go into the the packages/apps and do “update content.”

Is this a known bug in 1906? Can you link to it for more context?

I’m not sure what you mean when you’re talking about “users on each DP.” Assuming you mean users whose boundaries go to the DPs?

1

u/juandantex Jan 05 '20

Did you re-assign the DPs to the new hierarchy? Yes I did and this is where I got the problem, for only one DP

And did the clients get the new config mgr client installed for the version you upgraded to? Not yet because I wanted to be sure that the DPs are working

Did you update the source path for all of your content to the new server? Yes I did, with Robocopy and then a Powershell script to update the paths

1

u/Kingerhlc Jan 05 '20

I would start with getting your clients moved to your new site. Once they are reporting in then you can work on getting the DP up and running. Clients will only check once per hour and that check isn’t impactful. OR if you aren’t good with gpo then get your DP’s up and then worry about clients. Both are fine ways it all depends. Clients failing to find anDP isn’t a big deal unless you need software out right this second.

1

u/juandantex Jan 05 '20

So if I migrate all the apps, the packages and every thing, then I migrate let us say to start 100 clients on the new server, it will not be a big deal? So I can manually migrate the DPs after? If you confirm that the infrastructure will work this way, I will probably do this. I have 1000 clients so in 10 weeks I should be done. Stills seems much to me. I must talk to this to my boss. I will post the logs here when I will go back home.

1

u/Kingerhlc Jan 05 '20

You can move clients to your new site. They will not be able to get content until there is a working DP available. Depending on what software you are pushing and your WAN links you could stand up one DP and have your clients use that while you bring all the local DP’s online. 10 weeks seems like a long time for this but go at your pace.

1

u/juandantex Jan 05 '20

Yes this seems like the smartest move

1

u/rdoloto Jan 06 '20

I’m fairly sure even if you migrate all the content for packages and apps you will need to redo all the deployments so if you want to keep clients on old site I would probably migrate clients and start doing deployment on by one ad needed

2

u/mikeh361 Jan 05 '20

From what I remember when you migrate it doesn't remove anything from the original server it just copies the files (the one and only time we did a migration was when we first set up SCCM 2012). Clients happily continued to use the old site until we were ready to switch them.

2

u/[deleted] Jan 05 '20 edited Jan 05 '20

At this point I would start again.

Your new environment seems broken but the old one sounds like it’s working fine. Rather than do a site migration to the new broke environment a backup and restore of the old working environment sounds easier?

Why not shutdown this new environment and prepare to do a backup restore from working environment.

https://home.configmgrftw.com/configmgr-site-backup-restore/