CM12 - Day 2 in the lab
MP is barfing it has no DB perms. Since it's offbox, I guess CM12 still doesn't give it perms.
So what I do is add CM3$ to the local SQL User group on CM2. Then I create that group as a logon in SQL on CM2 and give it the smsdbrole_MP. Pain.
I'll see if this gets rid of my error 500 (usually means a SQL error) on CM3 (as revealed by site status error in the console).
Ramsey just pointed out that they have prereq docs on Connect – the one place I didn't look. I see that they do want ancient IIS Metabase compatibility among other things (at least for this shopping role). But does an MP need it? Gotta go see if there is more than the Shopping role doc Greg said.
The Software Catalog Web Service role requires the following to be installed on Windows Server 2008 site system servers:
- IIS 7.0 or IIS 7.5
- Microsoft .NET Framework 3.5 or higher
- Server Roles -> Web Server -> Application Development -> ASP.NET (and related components)
- Server Roles -> Web Server -> IIS 6 Management Compatibility -> IIS 6 Metabase Compatability
- Server Features -> .NET Framework Features -> WCF Activation
But nothing mentioning anything but that one role. I guess they assume we just keep all the same as CM07?
Well, adding the MP's machine acct isn't working: token based server access validation failed in the SQL logs on CM2. What did I forget to do?
Idiot. I added CM3$ to CM1's local SQL group, not CM2's. Should start to work in the next couple minutes. Yep, that did it (clean mpcontrol.log on CM3). Attn to detail is a must!
Now this is just MP beating on SQL remotely and not using its own transactional replica. I don't need to test that now as I assume nothing has changed; plus I don't know of any docs stating if the replica set has changed in any way. But I sure do hate that they haven't moved off transactional replication and automated this for MPs yet. I figured it'd be the 1st thing they'd have done.
I loathe client push, but in this case, I need to test it once. So I'll push to CM2. Worked. Client installed to C:\Windows\CCM (note that x64 boxes now get a real x64 client and the default client location is now Windows and not Windows\SysWow64.
Setting system group disc to every 12 hours and pointed to the root of the domain.
Hey cool, I never had to create a sender from CAS to DEV. Or back. It made them itself. That's cool!
Thinking about migration. I need an ID on the old central with permissions to CM and the DB. I could clone a strong user or group over there, but not sure I could use a machine acct and I DO want to use CM1$. So many I create a new AD group, put CM1$ into it, then grant it read on all objects in the console. But it'd also need SQL read & write. To make it simple, I could add CM1$ to my team's AD group acct, but anyone running psexec could do whatever they wanted – which they can now, but at least they're tracked. So it's sort of an auditing issue. But I get some leg work could still show who started psexec. So since this is my crappiest lab, I guess I'm going to do that for now.
OK, I got the migration analysis done and since it's a tiny lab, it took only seconds, not hours as warned.
When it finished, I clicked on the button to share DPs since it'd be nice to reuse the DP if possible (going to really want that in production).
That kicked off another run of the gathering tool. OK, so what now? What happened? Do I need to run the gather tool again? It's showing the CM07 DP, but is it using it? Maybe I'll try to park a package…
So I make my standard clitest program which is a package with a text file that has the word test in it plus a program called install with a command line of cmd /c
While making the program, I want to say that it can't run for more than a minute. But 15 min is the lowest I can go? Why? That could really hurt in some scenarios – like imaging – I need to bail fast and move on for some programs. Is there a bug for that? Search connect.
There – there are no DPs to park this to so what is left for migration to do to "share" the old CM07 DP?
Migration status says it's ready to gather again, so I'll kick off another gather job.
That did nothing, but I notice that I can right click that DP showing and choose to upgrade it. Well, why not? Here goes.
Says it will fail because it has other roles than DP. Really? Let me verify that. Wow, it had the old style ASP reporting point still on it. Blasting that and will probably have to run a gather cycle again.
- Created on .