A fully loaded shuttle ... includes lots of complex circuitry and moving parts, all of which can break. ... NASA will delay, or , a launch after detecting an existing or potential problem. Delaying the launch can allow threats to dissipate or give officials time to diagnose and repair problems." (excerpt from howstuffworks.com article)
And so it goes with our R3 upgrade. We've delayed our launch that was planned to go-live over this past weekend. We were not able to resolve our issue with Dynamics AX consistently serving up printer assignments. We believe it is an issue with remote desktop services and how it is communicating with Dynamics AX. We have a case open with Microsoft now. If you want to read more about our issue, you can go to my previous post "RD server printing issues...share your experiences, PLEASE!"
Never fear though, we will push forward! Stay tuned for more updates soon!
So I guess I'll have to spend my next few hours watching the total eclipse of the sun...
Monday, August 21, 2017
Saturday, August 5, 2017
Print drivers are loaded onto our RD servers and the list of printers are served up to each user using group policies. We have one print server.
We print using 2 types of label stock, some are continuous feed and others are perforated label stock. We have over a 100 label formats. Each label format includes printer settings. In AX, we have a customization that populates the label template with data, and then issues a print command.
Somehow ALL our label formats were updated to perforated. This caused quite a bit of havoc on our manufacturing floor because all our continuous feed printers started spewing out label stock and would not stop!!!
If we look at the label formats, the last updated dates are all different - some even very old. How did that happen?!? It seems some system operation updated them since the last updated date did not change. We had been testing in our R3 test environment as well as printing in our production environment.
Something is slowing down label printing. It can take up to a minute or more from when they issue the print command to when the first label is printed. If multiple labels were requested, this can get very slow. Sometimes the desired printer is not listed, and the user has to back out of the form and re-open in hopes that the printer list is updated. Is it RDP, Seagull, or Zebra -- whose holding onto those labels???
PLEASE, PLEASE, PLEASE share any thoughts...
The printer is idle...no printing is going on!!! Can't find my printer -or- it takes too long to print!!!
Okay, our issues are not that bad, but printing can be very slow coming out of AX.
We are using:
- Remote desktop services
- Group policies to determine what the user will see as their list of printers, this is because we have 4 main geographical areas
- Print drivers are loaded on each of the RD servers
- All printing goes through one print server
- Label printing uses a label interface application to Bartender
- Pixel perfect printing uses an application that has print forms that has some print management features
- Label formats and print forms share common folders between our R3 and current RTM environment
So now the story...
We've been working on an issue with our R3 environment. The printer list was not populating properly. It was not consistently serving up the complete list and/or the list that appears on the RD server is not matching the list that is seen once in AX. Our infrastructure team has been working on these issues the last week or so. We switched from roaming profiles to user profile disk. But that has not appeared to have solved it. They've done other things to try to help the situation, but I can't even begin to describe them!
Now coincidentally, we are having printing issues in our current RTM production environment. Is it related? We are not sure. The environments DO share the same print server. Could it be something we did on the R3 side that has inadvertently affected the RTM side? Or is our RTM RD printing having its own issue because it knows its getting eliminated!!! 😀
We've been wanting to look at another way to control our printing. Maybe the time has come, however at an unfortunate time - in the 11th hour of our R3 upgrade!!!
Anyone have ideas, experiences, or commiserating stories to share?!? Has anyone looked at ThinPrint, UniPrint, or TSPRINT? Any thoughts, opinions, ideas would be greatly appreciated by this PM!!!
Thursday, August 3, 2017
I hope you have enjoyed my Security Unwrapped Series!!! Written in these 9 posts is what I have learned in the past 5 years - during our AX implementation project as well as post implementation from AXUG Summit sessions, webinars, and online community posts!!!
I want to thank all the individuals and websites that have helped me along the way. Corey Bakhtiary of Arbela and Michael Cassidy of Fastpath, I've attended a number of your sessions! Microsoft's technet also provided many articles that were quite helpful. Brent Wilson and Jason Nightengale of Sikich Consulting for being patient and providing some security details with me during our AX Implementation Project. Matthew Maertern of Microsoft for answering many of my detailed questions last year before and after summit. And there were many others that I can't recall at the moment....my heartfelt thanks! I would not be here at this point of understanding without your help.
And now...I hope all of you that have followed my series, can fly like the planes in formation to successfully support Dynamics AX security for your organization!!!
Please share your comments, issues, or other areas you are interested in hearing about.
Hope to see you all at Summit in Nashville!!!
Tuesday, August 1, 2017
This post will unwrap some miscellaneous Security Tidbits. Some of the items noted are repeats of what I've posted already in this series, but thought to consolidate list here.
Management reporter inherits its security from the user's Dynamics AX security. Below are the access levels in Management Reporter and the privilege/duty that will grant MR access.
BI Cubes and associated AX reports:
Standard AX cubes are built and loaded using background jobs. Several reports in AX access the BI cubes to create the report. Many (but not all) of the reports have the word statistical in the report name. To access these reports requires some additional access to be set up. The BI cubes reside on the SSAS server, that server has role groups that the user must be a member to access the cube and hence access the statistical report. The error you will receive if the user does not have access is:
"Either the user, <domain>\<userid>, does not have access to the Dynamics AX database, or the database does not exist." Below is a list of the various role groups:
Blocking users from Journals:
You can setup secondary access to limit the set of users that have access to posting inventory and general ledger journals. This is done by defining user groups and using the "Blocking" feature on the journal name setup form. Refer to my prior post: Security Unwrapped Series: Supplemental Setups for details.
Limiting users to specific organizations (aka legal entities):
By default when assigning access, the user will have access to all organizations. If you want to limit them to specific organization (or legal entities), you can by granting by organization. See my prior post: Security Unwrapped Series: Explaining the Security Menu for details.
Purchase requisition access:
By granting the Employee role to a user gives them access to create purchase requisitions. However there is additional setups required before they can create a purchase requisition. The navigation path is: Procurement and sourcing\setup\Policies\Purchase requisition permissions,
Each legal entity they are allowed to create a requisition in must be discretely granted - choose the view "By requester" and add the specific legal entities:
You can also grant an individual to create purchase requisitions in behalf of another person - choose the view - By preparer and choose the individuals they will be preparing purchase requisitions for:
Preventing updates to approved BOMs:
You can block updates to approved bills of materials by updating a parameter setting in the Inventory Management module. Please refer to Kelly Kane's AX Soup blog entry: Don't Change my BOMs!
Other miscellaneous items:
1. System administrator role can only be assigned by another System administrator. Security administrators cannot assign this role to a user.
2. Deleting a role, duty, privilege, or process in the UI does not delete the AOT security object. You must go to the AOT to perform the delete. If this is not done, it will cause a compile error.
3. Enterprise portal also has its own security. (I have not yet played with this, so will not add any details right now. BUT expect it someday in the future!)
4. Nesting roles is allowed and compiles without issue. However the security add-in tool will only display correctly. See my prior post: Security Unwrapped Series: Security Add-in Features for more details.
5. When using the UI, your security elements will be in the USR layer. When moving to Dynamics 365, this will be an issue. This is because in Dynamics 365 security is compiled and stored as metadata. To retain the security changes in the AOT, you will need to have a developer access the AOT to make the changes permanent.